Failed making perl5 at lib/buildcustomize.pl #17054
Comments
From imdb95@gmail.comCreated by imdb95@gmail.comI am trying to build Perl with American Fuzzing Lop, but have failed. This is perl 5, version 31, subversion 1 (v5.31.1 (UNKNOWN-miniperl)) built [Run]: AFL_USE_ASAN=1 make
0x6020000006b0 is located 0 bytes inside of 8-byte region
0x6020000006b0 is located 0 bytes inside of 8-byte region previously allocated by thread T0 here: SUMMARY: AddressSanitizer: heap-use-after-free [Run]: AFL_USE_ASAN=1 make minitest Please fix the bug. Perl Info |
From @jkeenanOn Thu, 20 Jun 2019 09:44:34 GMT, imdb95@gmail.com wrote:
Can you supply the full ./Configure command (i.e., all switches) which you used in this attempt to build with AFL? Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From imdb95@gmail.comThe full commands I compiled: 2. AFL_USE_ASAN=1 make One important clue: I built it on "Ubuntu 16.04 LTS Minimal" of Google On Sat, Jun 22, 2019 at 9:14 PM James E Keenan via RT <
|
From @jkeenan[We prefer bottom-posting; rearranging comments.]
On Sat, 22 Jun 2019 21:12:49 GMT, imdb95@gmail.com wrote:
Aha! You said the magic word: Google Cloud. This is probably the first bug report we have heard from some one attempting to build on Google Cloud. So we have no idea how well Perl 5 is supported on that platform. So, several questions: 1. Can you build perl-5.31.1 on Google clouds with these more typical configurations? a. sh ./Configure -des -Dusedevel 2. Can you build the latest *production* release of Perl (5.30.0) on Google Cloud with the above configurations? 3. Can you build perl-5.30.0 with the fuzzing switches on Google Cloud? 4. Have you been able to build earlier production releases of Perl (e.g., 5.24, 5.26, 5.28) with the fuzzing switches on Google Cloud? Thank you very much. -- |
From @tonycozOn Thu, 20 Jun 2019 02:44:34 -0700, imdb95@gmail.com wrote:
Is there any chance you can get valgrind on the VM? If so, can you run: valgrind ./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' after the failed build? valgrind tends to provide better diagnostics on a use after free than ASAN. Thanks, |
From @tonycozOn Sun, 23 Jun 2019 18:19:35 -0700, tonyc wrote:
While this would still be useful, I have a suspicion of the cause. READ of size 2 at 0x6020000006b0 thread T0 Here's the code in question (minus the irrelevant code): const char * locale_name_on_entry; LC_NUMERIC_LOCK(0); /* Start critical section */ locale_name_on_entry = setlocale(LC_NUMERIC, NULL); <-- get current locale name (possibly malloced()) ... if (locale_name_on_entry) { The lifetime of the string returned by setlocale() isn't well documented, but it is documented that it *may* be return a pointer to static storage, in which case the setlocale(LC_NUMERIC, "C") may overwrite it, making the value useless for restoring the locale. The attached should fix it. #134182 (which I found after checking the version.pm PRs) has an incomplete patch for this. Tony |
From @tonycoz0001-perl-134212-ensure-locale_name_on_entry-isn-t-clobbe.patchFrom 1fe5ce568b3606d1c33ff4e8cb5cace78c2cbaf4 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Mon, 16 Sep 2019 16:38:26 +1000
Subject: (perl #134212) ensure locale_name_on_entry isn't clobbered
If the return value of setlocale() is static storage, the call to
setlocale(LC_NUMERIC, "C"); could overwrite it.
If the return value of setlocale() is malloced, the call to
setlocale(LC_NUMERIC, "C"); could free it.
Either way, we need to copy it
---
t/porting/customized.dat | 2 +-
vutil.c | 6 ++++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/t/porting/customized.dat b/t/porting/customized.dat
index b386353b7c..d3af0693e7 100644
--- a/t/porting/customized.dat
+++ b/t/porting/customized.dat
@@ -24,4 +24,4 @@ autodie cpan/autodie/t/mkdir.t 9e70d2282a3cc7d76a78bf8144fccba20fb37dac
autodie cpan/autodie/t/recv.t 63bea2daa330e44b67714527ddf701c1bf3a6954
experimental cpan/experimental/t/basic.t cb9da8dd05b854375809872a05dd32637508d5da
version cpan/version/lib/version.pm 7ef9219d1d5f1d71f08a79f3b0577df138b21b12
-version vutil.c 317c25a807f9503282d58917a4a53b667232a6c5
+version vutil.c 601cc57bbc0070ae33eab7fd2d667f20efbe15f8
diff --git a/vutil.c b/vutil.c
index 4314fb9280..23627bea78 100644
--- a/vutil.c
+++ b/vutil.c
@@ -643,6 +643,8 @@ VER_NV:
if ( strNE(locale_name_on_entry, "C")
&& strNE(locale_name_on_entry, "POSIX"))
{
+ /* the setlocale() call might free or overwrite the name */
+ locale_name_on_entry = savepv(locale_name_on_entry);
setlocale(LC_NUMERIC, "C");
}
else { /* This value indicates to the restore code that we didn't
@@ -666,6 +668,8 @@ VER_NV:
if ( strNE(locale_name_on_entry, "C")
&& strNE(locale_name_on_entry, "POSIX"))
{
+ /* the setlocale() call might free or overwrite the name */
+ locale_name_on_entry = savepv(locale_name_on_entry);
setlocale(LC_NUMERIC, "C");
}
else { /* This value indicates to the restore code that we
@@ -715,6 +719,7 @@ VER_NV:
if (locale_name_on_entry) {
setlocale(LC_NUMERIC, locale_name_on_entry);
+ Safefree(locale_name_on_entry);
}
LC_NUMERIC_UNLOCK; /* End critical section */
@@ -723,6 +728,7 @@ VER_NV:
if (locale_name_on_entry) {
setlocale(LC_NUMERIC, locale_name_on_entry);
+ Safefree(locale_name_on_entry);
LC_NUMERIC_UNLOCK;
}
else if (locale_obj_on_entry == PL_underlying_numeric_obj) {
--
2.11.0
|
From @khwilliamsonOn Sun, 15 Sep 2019 23:53:04 -0700, tonyc wrote:
Why not just do a saave the first time? It would be less code that could get out of sync. When it is unclear what is going to happen in the interim, locale.c makes it a SAVEFREEPV |
From @tonycozOn Mon, Sep 16, 2019 at 01:37:00PM -0700, Karl Williamson via RT wrote:
I had a WIP that used SAVEFREEPV(), but in this case we have an Or did I misunderstand what you're asking here? Tony |
From @khwilliamsonOn 9/16/19 7:23 PM, Tony Cook wrote:
I hadn't examined it enough in detail to realize there was only one
|
From imdb95@gmail.comI tried valgrind and valgrind seems detect nothing: root@manh-ubuntu16:~/fuzz/fuzz_perl/perl_dbg# valgrind ./miniperl -w -Ilib Still there's no patch? On Thu, Sep 19, 2019 at 7:31 AM karl williamson via RT <
|
|
From Here's the link for reference: https://sourceware.org/bugzilla/show_bug.cgi?id=25123 |
|
@tonycoz ^^ |
|
@ManhNDd ^^ |
If the return value of setlocale() is static storage, the call to setlocale(LC_NUMERIC, "C"); could overwrite it. If the return value of setlocale() is malloced, the call to setlocale(LC_NUMERIC, "C"); could free it. Either way, we need to copy it. Fixes gh Perl#17054 rt134212
If the return value of setlocale() is static storage, the call to setlocale(LC_NUMERIC, "C"); could overwrite it. If the return value of setlocale() is malloced, the call to setlocale(LC_NUMERIC, "C"); could free it. Either way, we need to copy it. Fixes gh #17054 rt134212
Migrated from rt.perl.org#134212 (status was 'open')
Searchable as RT134212$
The text was updated successfully, but these errors were encountered: