[Bug general/32155] New: elfutils fails to compile with "srcfiles.cxx:354:10: error: use of undeclared identifier 'no_backup'"
https://sourceware.org/bugzilla/show_bug.cgi?id=32155
Bug ID: 32155
Summary: elfutils fails to compile with "srcfiles.cxx:354:10:
error: use of undeclared identifier 'no_backup'"
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: general
Assignee: unassigned at sourceware dot org
Reporter: evvers at ya dot ru
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
I'm trying to figure out why elfutils started failing to compile on OSS-Fuzz.
https://oss-fuzz-build-logs.storage.googleapis.com/index.html#elfutils.
According to `git bisect` the first commit where it started failing with that
particular error was
https://sourceware.org/git/?p=elfutils.git;a=commit;h=d6443d1a4df6057f9012d105037f52daaca911f1
but trying to reproduce it locally I ran into another build failure:
```
libdwelf -I./../libdwfl -I./../libasm -I../debuginfod -std=c++11 -Wall
-Wshadow-Wnull-dereference -Wimplicit-fallthrough -Werror -Wunused -Wextra
-D_FORTIFY_SOURCE=3 -Wno-error -O1 -fno-omit-frame-pointer -g
-DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address
-fsanitize=fuzzer-no-link -MT srcfiles.o -MD -MP -MF .deps/srcfiles.Tpo -c -o
srcfiles.o srcfiles.cxx
srcfiles.cxx:354:10: error: use of undeclared identifier 'no_backup'
354 | if (!no_backup)
| ^
1 error generated.
```
The script configuring elfutils there runs
```
./configure --enable-maintainer-mode --disable-debuginfod
--disable-libdebuginfod \
--disable-demangler --without-bzlib --without-lzma --without-zstd
```
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/32155] elfutils fails to compile with "srcfiles.cxx:354:10: error: use of undeclared identifier 'no_backup'"
https://sourceware.org/bugzilla/show_bug.cgi?id=32155 --- Comment #1 from Evgeny Vereshchagin --- On a somewhat related note I can't seem to find any notifications from OSS-Fuzz on the elfutils mailing list: https://sourceware.org/pipermail/elfutils-devel/2024q3/thread.html. Could it be that they bounced? Or should it be reported to OSS-Fuzz that their notifications haven't been sent? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/32155] elfutils fails to compile with "srcfiles.cxx:354:10: error: use of undeclared identifier 'no_backup'"
https://sourceware.org/bugzilla/show_bug.cgi?id=32155 --- Comment #2 from Evgeny Vereshchagin --- The OSS-Fuzz build failure should be fixed in https://github.com/google/oss-fuzz/pull/12465. The "use of undeclared identifier 'no_backup'" error doesn't affect OSS-Fuzz builds because libarchive isn't present there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/32155] elfutils fails to compile with "srcfiles.cxx:354:10: error: use of undeclared identifier 'no_backup'"
https://sourceware.org/bugzilla/show_bug.cgi?id=32155 --- Comment #5 from Evgeny Vereshchagin --- I applied the patch locally and as far as I can see elfutils no longer fails to compile. Thank you! > There have been emails from "monorail" which contained fuzz reports Got it. It seems the part responsible for opening issues on Monorail broke recently. I added a comment to https://github.com/google/oss-fuzz/issues/12446 and mentioned that build failures aren't reported. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28654] New: There seems to be an infinite loop somewhere in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28654 Bug ID: 28654 Summary: There seems to be an infinite loop somewhere in dwfl_segment_report_module Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13822 --> https://sourceware.org/bugzilla/attachment.cgi?id=13822&action=edit file triggering an infinite loop in dwfl_segment_report_module One of systemd fuzz targets discovered what seems to be an infinite loop in dwfl_segment_report_module. It can be reproduced by building the master branch of the elfutils repository and passing the attachment to `./src/stack`: ``` $ git describe elfutils-0.186-7-g99782bd2 ``` ``` autoreconf -i -f ./configure --enable-maintainer-mode make -j$(nproc) V=1 LD_PRELOAD="./libelf/libelf.so ./libdw/libdw.so" ./src/stack --core oss-fuzz-41572 ``` According to `eu-stack` it's in dwfl_segment_report_module ``` #0 0x7fa48b3eecf3 dwfl_segment_report_module #1 0x7fa48b3f2c88 dwfl_core_file_report@@ELFUTILS_0.158 #2 0x00402ec7 parse_opt #3 0x7fa48b0abf82 argp_parse #4 0x004024eb main #5 0x7fa48afc6b75 __libc_start_main #6 0x0040272e _start ``` It was also reported in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41572 ``` ALARM: working on the last Unit for 61 seconds and the timeout value is 60 (use -timeout=N to change) ==782== ERROR: libFuzzer: timeout after 61 seconds #0 0x52fdb1 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:87:3 #1 0x4707e8 in fuzzer::PrintStackTrace() cxa_noexception.cpp:0 #2 0x455679 in fuzzer::Fuzzer::AlarmCallback() cxa_noexception.cpp:0 #3 0x7ff8fd7473bf in libpthread.so.0 #4 0x46e23c in HandleCmp /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:390:31 #5 0x46e23c in __sanitizer_cov_trace_cmp8 /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:483:15 #6 0x5f6edb in dwfl_segment_report_module /src/elfutils/libdwfl/dwfl_segment_report_module.c:546:29 #7 0x567135 in dwfl_core_file_report /src/elfutils/libdwfl/core-file.c:559:17 #8 0x55f280 in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6 #9 0x456ca3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp:0 #10 0x4425b2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #11 0x44807a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp:0 #12 0x470fa2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #13 0x7ff8fd53b0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 #14 0x41f83d in _start SUMMARY: libFuzzer: timeout ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28655] New: There seems to be a memory leak in file_read_elf
https://sourceware.org/bugzilla/show_bug.cgi?id=28655 Bug ID: 28655 Summary: There seems to be a memory leak in file_read_elf Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13823 --> https://sourceware.org/bugzilla/attachment.cgi?id=13823&action=edit File triggering a memory leak One of systemd fuzz targets discovered a memory leak in file_read_elf. It can be reproduced by building the master branch of the elfutils repository and passing the attachment to `./src/stack` run under Valgrind ``` autoreconf -i -f ./configure --enable-maintainer-mode make -j$(nproc) V=1 LD_PRELOAD="./libelf/libelf.so ./libdw/libdw.so" valgrind --leak-check=full ./src/stack --core ../oss-fuzz-41568 ... ==63344== HEAP SUMMARY: ==63344== in use at exit: 16,722,041 bytes in 108 blocks ==63344== total heap usage: 4,580 allocs, 4,472 frees, 16,980,258 bytes allocated ==63344== ==63344== 264 bytes in 1 blocks are definitely lost in loss record 9 of 19 ==63344==at 0x4845464: calloc (vg_replace_malloc.c:1328) ==63344==by 0x4855711: allocate_elf (common.h:74) ==63344==by 0x4855711: file_read_elf (elf_begin.c:320) ==63344==by 0x485607A: __libelf_read_mmaped_file (elf_begin.c:559) ==63344==by 0x48C52AA: dwfl_segment_report_module (dwfl_segment_report_module.c:955) ==63344==by 0x48C7C87: dwfl_core_file_report@@ELFUTILS_0.158 (core-file.c:559) ==63344==by 0x402EC6: parse_opt (stack.c:595) ==63344==by 0x4C3AF81: argp_parse (in /usr/lib64/libc-2.33.so) ==63344==by 0x4024EA: main (stack.c:695) ==63344== ``` It was also reported in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41568 ``` ==618914==ERROR: LeakSanitizer: detected memory leaks Direct leak of 264 byte(s) in 1 object(s) allocated from: #0 0x526002 in __interceptor_calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 #1 0x636d4e in allocate_elf /src/elfutils/libelf/common.h:74:17 #2 0x636d4e in file_read_elf /src/elfutils/libelf/elf_begin.c:320:14 #3 0x6362aa in __libelf_read_mmaped_file /src/elfutils/libelf/elf_begin.c:559:14 #4 0x64ba42 in elf_memory /src/elfutils/libelf/elf_memory.c:49:10 #5 0x5f9867 in dwfl_segment_report_module /src/elfutils/libdwfl/dwfl_segment_report_module.c:955:13 #6 0x567135 in dwfl_core_file_report /src/elfutils/libdwfl/core-file.c:559:17 #7 0x55f280 in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6 #8 0x456ca3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp:0 #9 0x4425b2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #10 0x44807a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp:0 #11 0x470fa2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #12 0x7fe13555c0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28657] New: UBSan seems to report a divison-by-zero in dwfl_link_map_report
https://sourceware.org/bugzilla/show_bug.cgi?id=28657 Bug ID: 28657 Summary: UBSan seems to report a divison-by-zero in dwfl_link_map_report Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13824 --> https://sourceware.org/bugzilla/attachment.cgi?id=13824&action=edit File triggering a "division-by-zero" One of systemd fuzz target run under UBSan discovered a "divison-by-zero". It can be reproduced by building the master branch of the elfutils repository with UBSan and passing the attachment to `./src/stack` ``` $ git describe elfutils-0.186-7-g99782bd2 autoreconf -i -f ./configure --enable-maintainer-mode CFLAGS='-g -O1 -fno-omit-frame-pointer' --enable-sanitize-undefined CXXFLAGS='-g -O1 -fno-omit-frame-pointer' make -j$(nproc) V=1 LD_PRELOAD="./libelf/libelf.so ./libdw/libdw.so" UBSAN_OPTIONS=print_stacktrace=1:print_summary=1 ./src/stack --core ../oss-fuzz-41574 link_map.c:873:12: runtime error: division by zero #0 0x7f93972cf29a in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:873 #1 0x7f93972d25c7 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:548 #2 0x402b0f in parse_opt /home/vagrant/elfutils/src/stack.c:595 #3 0x7f939654df81 in __argp_parse (/lib64/libc.so.6+0x10cf81) #4 0x403d98 in main /home/vagrant/elfutils/src/stack.c:695 #5 0x7f9396468b74 in __libc_start_main (/lib64/libc.so.6+0x27b74) #6 0x4024cd in _start (/home/vagrant/elfutils/src/stack+0x4024cd) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior link_map.c:873:12 in ``` It was also reported in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41574 ``` Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-747fcf4f5bf93741e8fc31e9cbb44a70865e4c07 link_map.c:873:12: runtime error: division by zero #0 0x51cae6 in dwfl_link_map_report /src/elfutils/libdwfl/link_map.c:873:12 #1 0x4b868b in dwfl_core_file_report /src/elfutils/libdwfl/core-file.c:548:16 #2 0x4b363e in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6 #3 0x43f1b3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp:0 #4 0x42aac2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #5 0x43058a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp:0 #6 0x4594b2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #7 0x7f2bedb160b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 #8 0x407d4d in _start SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior link_map.c:873:12 in ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28658] New: UBSan seems to report a divison-by-zero in dwfl_link_map_report
https://sourceware.org/bugzilla/show_bug.cgi?id=28658 Bug ID: 28658 Summary: UBSan seems to report a divison-by-zero in dwfl_link_map_report Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- One of systemd fuzz target run under UBSan discovered a "divison-by-zero". It can be reproduced by building the master branch of the elfutils repository with UBSan and passing the attachment to `./src/stack` ``` $ git describe elfutils-0.186-7-g99782bd2 autoreconf -i -f ./configure --enable-maintainer-mode CFLAGS='-g -O1 -fno-omit-frame-pointer' --enable-sanitize-undefined CXXFLAGS='-g -O1 -fno-omit-frame-pointer' make -j$(nproc) V=1 LD_PRELOAD="./libelf/libelf.so ./libdw/libdw.so" UBSAN_OPTIONS=print_stacktrace=1:print_summary=1 ./src/stack --core ../oss-fuzz-41574 link_map.c:873:12: runtime error: division by zero #0 0x7f93972cf29a in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:873 #1 0x7f93972d25c7 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:548 #2 0x402b0f in parse_opt /home/vagrant/elfutils/src/stack.c:595 #3 0x7f939654df81 in __argp_parse (/lib64/libc.so.6+0x10cf81) #4 0x403d98 in main /home/vagrant/elfutils/src/stack.c:695 #5 0x7f9396468b74 in __libc_start_main (/lib64/libc.so.6+0x27b74) #6 0x4024cd in _start (/home/vagrant/elfutils/src/stack+0x4024cd) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior link_map.c:873:12 in ``` It was also reported in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41574 ``` Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-747fcf4f5bf93741e8fc31e9cbb44a70865e4c07 link_map.c:873:12: runtime error: division by zero #0 0x51cae6 in dwfl_link_map_report /src/elfutils/libdwfl/link_map.c:873:12 #1 0x4b868b in dwfl_core_file_report /src/elfutils/libdwfl/core-file.c:548:16 #2 0x4b363e in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6 #3 0x43f1b3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp:0 #4 0x42aac2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #5 0x43058a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp:0 #6 0x4594b2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #7 0x7f2bedb160b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 #8 0x407d4d in _start SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior link_map.c:873:12 in ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28658] UBSan seems to report a divison-by-zero in dwfl_link_map_report
https://sourceware.org/bugzilla/show_bug.cgi?id=28658 Evgeny Vereshchagin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Evgeny Vereshchagin --- I'm not sure why it was reported twice. It's the same as https://sourceware.org/bugzilla/show_bug.cgi?id=28657 *** This bug has been marked as a duplicate of bug 28657 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28657] UBSan seems to report a divison-by-zero in dwfl_link_map_report
https://sourceware.org/bugzilla/show_bug.cgi?id=28657 --- Comment #1 from Evgeny Vereshchagin --- *** Bug 28658 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28659] New: UBSan seems to complain about an "integer overflow" in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28659 Bug ID: 28659 Summary: UBSan seems to complain about an "integer overflow" in dwfl_segment_report_module Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13825 --> https://sourceware.org/bugzilla/attachment.cgi?id=13825&action=edit File triggering an integer overflow One of systemd fuzz targets run under UBSan discovered an "integer-overflow". It can be reproduced by building the master branch of the elfutils repository with UBSan and passing the attachment to `./src/stack`: ``` $ git describe elfutils-0.186-7-g99782bd2 autoreconf -i -f ./configure --enable-maintainer-mode CFLAGS='-g -O1 -fno-omit-frame-pointer' --enable-sanitize-undefined make -j$(nproc) V=1 LD_PRELOAD="./libelf/libelf.so ./libdw/libdw.so" UBSAN_OPTIONS=print_stacktrace=1:print_summary=1 ./src/stack --core ../oss-fuzz-41570 dwfl_segment_report_module.c:400:55: runtime error: signed integer overflow: 65535 * 65312 cannot be represented in type 'int' #0 0x7f48c29c057e in dwfl_segment_report_module /home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:400 #1 0x7f48c29c7656 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:559 #2 0x402b0f in parse_opt /home/vagrant/elfutils/src/stack.c:595 #3 0x7f48c1c42f81 in __argp_parse (/lib64/libc.so.6+0x10cf81) #4 0x403d98 in main /home/vagrant/elfutils/src/stack.c:695 #5 0x7f48c1b5db74 in __libc_start_main (/lib64/libc.so.6+0x27b74) #6 0x4024cd in _start (/home/vagrant/elfutils/src/stack+0x4024cd) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior dwfl_segment_report_module.c:400:55 in ``` It was also reported in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41570 ``` Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-4613ca6be3014e2d8019781ba5061e2ebaad886f dwfl_segment_report_module.c:400:55: runtime error: signed integer overflow: 65535 * 65312 cannot be represented in type 'int' #0 0x51915d in dwfl_segment_report_module /src/elfutils/libdwfl/dwfl_segment_report_module.c:400:55 #1 0x4b86e7 in dwfl_core_file_report /src/elfutils/libdwfl/core-file.c:559:17 #2 0x4b363e in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6 #3 0x43f1b3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp:0 #4 0x42aac2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #5 0x43058a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp:0 #6 0x4594b2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #7 0x7f0cfd13e0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 #8 0x407d4d in _start SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior dwfl_segment_report_module.c:400:55 in ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28660] New: ASan seems to complain about a "heap-buffer-overflow"
https://sourceware.org/bugzilla/show_bug.cgi?id=28660 Bug ID: 28660 Summary: ASan seems to complain about a "heap-buffer-overflow" Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13826 --> https://sourceware.org/bugzilla/attachment.cgi?id=13826&action=edit File triggering a heap-buffer-overflow One of systemd fuzz targets triggered a "heap-buffer-overflow". It can be reproduced by building the master branch of the elfutils repository with ASan and passing the attachment to `./src/stack`: ``` $ git describe elfutils-0.186-7-g99782bd2 autoreconf -i -f ./configure --enable-maintainer-mode CFLAGS='-g -O1 -fno-omit-frame-pointer -fsanitize=address' CXXFLAGS='-g -O1 -fno-omit-frame-pointer -fsanitize=address' ASAN_OPTIONS=detect_leaks=0 make -j$(nproc) V=1 LD_PRELOAD="/lib64/libasan.so.6 ./libelf/libelf.so ./libdw/libdw.so" UBSAN_OPTIONS=print_stacktrace=1:print_summary=1 ./src/stack --core ../oss-fuzz-41566 = ==85112==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60201b70 at pc 0x7f96b3109a31 bp 0x7ffebaf7f470 sp 0x7ffebaf7f468 READ of size 4 at 0x60201b70 thread T0 #0 0x7f96b3109a30 in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:904 #1 0x7f96b310e877 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:548 #2 0x4037b8 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #3 0x7f96b2d05f81 in __argp_parse (/lib64/libc.so.6+0x10cf81) #4 0x404b7d in main /home/vagrant/elfutils/src/stack.c:695 #5 0x7f96b2c20b74 in __libc_start_main (/lib64/libc.so.6+0x27b74) #6 0x40256d in _start (/home/vagrant/elfutils/src/stack+0x40256d) 0x60201b71 is located 0 bytes to the right of 1-byte region [0x60201b70,0x60201b71) allocated by thread T0 here: #0 0x7f96b32b693f in __interceptor_malloc (/lib64/libasan.so.6+0xae93f) #1 0x7f96b31096c4 in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:879 #2 0x7f96b310e877 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:548 #3 0x4037b8 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #4 0x7f96b2d05f81 in __argp_parse (/lib64/libc.so.6+0x10cf81) #5 0x404b7d in main /home/vagrant/elfutils/src/stack.c:695 #6 0x7f96b2c20b74 in __libc_start_main (/lib64/libc.so.6+0x27b74) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/vagrant/elfutils/libdwfl/link_map.c:904 in dwfl_link_map_report Shadow bytes around the buggy address: 0x0c047fff8310: fa fa 00 03 fa fa 00 04 fa fa fd fa fa fa fd fa 0x0c047fff8320: fa fa 00 03 fa fa 00 04 fa fa fd fa fa fa fd fa 0x0c047fff8330: fa fa 00 03 fa fa 00 04 fa fa fd fa fa fa fd fa 0x0c047fff8340: fa fa 00 03 fa fa 00 04 fa fa fd fa fa fa fd fa 0x0c047fff8350: fa fa 00 03 fa fa 00 04 fa fa fd fa fa fa fd fa =>0x0c047fff8360: fa fa 00 03 fa fa 00 04 fa fa 00 04 fa fa[01]fa 0x0c047fff8370: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8390: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff83a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff83b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==85112==ABORTING ``` It was also reported in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41566 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom
https://sourceware.org/bugzilla/show_bug.cgi?id=28666 Evgeny Vereshchagin changed: What|Removed |Added CC||evvers at ya dot ru --- Comment #1 from Evgeny Vereshchagin --- FWIW There are a lot of moving parts there so in https://github.com/google/oss-fuzz/pull/6944 I tried to make it easier to reproduce bugs found by the fuzz target without Docker used by the oss-fuzz toolchain. To that end I added a comment where I tried to explain how to build it manually with clang and the build dependencies of elfutils: https://github.com/google/oss-fuzz/blob/5f83a8b6811eaa6b1a0aa574e095ed0def8a0ce3/projects/elfutils/build.sh#L18-L36. Apart from that I'm pretty sure all the bugs that can be found by the fuzz target (in its current form at least) can be triggered with `./src/stack --core ...` built with ASan/UBsan or under Valgrind so this particular issue can be triggered by running something like ``` autoreconf -i -f ./configure --enable-maintainer-mode CFLAGS='-g -O1 -fno-omit-frame-pointer -fsanitize=address' CXXFLAGS='-g -O1 -fno-omit-frame-pointer -fsanitize=address' ASAN_OPTIONS=detect_leaks=0 make -j$(nproc) V=1 $ LD_PRELOAD="/lib64/libasan.so.6 ./libelf/libelf.so ./libdw/libdw.so" ./src/stack --core ../poc1 AddressSanitizer:DEADLYSIGNAL = ==52660==ERROR: AddressSanitizer: SEGV on unknown address 0x7fd5b4e5d000 (pc 0x7fd5b8a86368 bp 0x7fff4773cb50 sp 0x7fff4773cb18 T0) ==52660==The signal is caused by a READ memory access. #0 0x7fd5b8a86368 in __sanitizer::internal_memmove(void*, void const*, unsigned long) (/lib64/libasan.so.6+0xc5368) #1 0x7fd5b898aa42 in memmove /usr/include/bits/string_fortified.h:36 #2 0x7fd5b898aa42 in elf32_xlatetom /home/vagrant/elfutils/libelf/elf32_xlatetom.c:96 #3 0x7fd5b88c285b in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:895 #4 0x7fd5b88c7877 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:548 #5 0x4037b8 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #6 0x7fd5b84bef81 in __argp_parse (/lib64/libc.so.6+0x10cf81) #7 0x404b7d in main /home/vagrant/elfutils/src/stack.c:695 #8 0x7fd5b83d9b74 in __libc_start_main (/lib64/libc.so.6+0x27b74) #9 0x40256d in _start (/home/vagrant/elfutils/src/stack+0x40256d) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.6+0xc5368) in __sanitizer::internal_memmove(void*, void const*, unsigned long) ==52660==ABORTING ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom
https://sourceware.org/bugzilla/show_bug.cgi?id=28666 --- Comment #4 from Evgeny Vereshchagin --- With that patch applied I can confirm that the issue is gone.Just to make sure also run the unit tests on aarch64, i386, ppc64le and x86_64 and they all passed there. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28654] There seems to be an infinite loop somewhere in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28654 --- Comment #2 from Evgeny Vereshchagin --- I applied the patch on top of the master branch with the other two patches related to libwfl applied and ran `src/stack` under Valgrind. I also ran the unit tests on four different architectures just in case and they all passed there. Looks like the issue is gone. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28660] ASan seems to complain about a "heap-buffer-overflow"
https://sourceware.org/bugzilla/show_bug.cgi?id=28660 --- Comment #2 from Evgeny Vereshchagin --- As far as I can see both issues are gone with that patch applied. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom
https://sourceware.org/bugzilla/show_bug.cgi?id=28666 --- Comment #5 from Evgeny Vereshchagin --- I was able to trigger the same issue with a different file by running the fuzz target a bit longer. I'll double check and attach the file -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom
https://sourceware.org/bugzilla/show_bug.cgi?id=28666 --- Comment #6 from Evgeny Vereshchagin --- My bad. The backtrace is different there: ``` 2021-12-08T20:14:08.7167911Z ==21==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f4f1d328000 at pc 0x00524c9f bp 0x7fff9271bc40 sp 0x7fff9271b408 2021-12-08T20:14:08.7169143Z READ of size 327680 at 0x7f4f1d328000 thread T0 2021-12-08T20:14:08.7170393Z SCARINESS: 26 (multi-byte-read-heap-buffer-overflow) 2021-12-08T20:14:08.7429032Z #0 0x524c9e in __asan_memmove /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:30:3 2021-12-08T20:14:08.7434627Z #1 0x63d0b3 in memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:40:10 2021-12-08T20:14:08.7438180Z #2 0x63d0b3 in elf32_xlatetom /src/elfutils/libelf/elf32_xlatetom.c:96:2 2021-12-08T20:14:08.7441601Z #3 0x5fc7e8 in dwfl_link_map_report /src/elfutils/libdwfl/link_map.c:1013:12 2021-12-08T20:14:08.7445515Z #4 0x5668da in dwfl_core_file_report /src/elfutils/libdwfl/core-file.c:548:16 2021-12-08T20:14:08.7448767Z #5 0x55eaa0 in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6 ``` I think the issue reported here is gone. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28659] UBSan seems to complain about an "integer overflow" in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28659 --- Comment #2 from Evgeny Vereshchagin --- > Note that the overflow is actually harmless It is but since the fuzz target ran into it almost as soon as it started it prevented the fuzz target from discovering new issues that can be less harmless though. Looks like the issue is gone. Thanks! FWIW judging by https://github.com/evverx/elfutils/pull/40#issuecomment-989275575, it fixed one LGTM alert as well. I'm not sure if I mentioned this anywhere but LGTM builds those reports on a daily basis and those reports can be found at https://lgtm.com/projects/g/evverx/elfutils/alerts/?mode=tree . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28655] There seems to be a memory leak in file_read_elf
https://sourceware.org/bugzilla/show_bug.cgi?id=28655 --- Comment #2 from Evgeny Vereshchagin --- I can't seem to reproduce that memory leak anymore. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom
https://sourceware.org/bugzilla/show_bug.cgi?id=28666 --- Comment #8 from Evgeny Vereshchagin --- Created attachment 13840 --> https://sourceware.org/bugzilla/attachment.cgi?id=13840&action=edit File triggering an "invalid read" I've just added a file triggering that issue. ``` $ git describe elfutils-0.186-20-g98e7adf7 autoreconf -i -f ./configure --enable-maintainer-mode make -j$(nproc) V=1 $ DEBUGINFOD_URLS= LD_PRELOAD="./libelf/libelf.so ./libdw/libdw.so" valgrind --leak-check=full ./src/stack --core ../crash-51ef1bcb1fbd741ff5fde645079625a8ed871225 ==55019== Memcheck, a memory error detector ==55019== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==55019== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==55019== Command: ./src/stack --core ../crash-51ef1bcb1fbd741ff5fde645079625a8ed871225 ==55019== ==55019== Invalid read of size 8 ==55019==at 0x484B214: memmove (vg_replace_strmem.c:1382) ==55019==by 0x48585DF: memmove (string_fortified.h:36) ==55019==by 0x48585DF: elf32_xlatetom (elf32_xlatetom.c:96) ==55019==by 0x48C793A: dwfl_link_map_report (link_map.c:1013) ==55019==by 0x48C8CA5: dwfl_core_file_report@@ELFUTILS_0.158 (core-file.c:548) ==55019==by 0x402EC6: parse_opt (stack.c:595) ==55019==by 0x4C4D591: argp_parse (in /usr/lib64/libc.so.6) ==55019==by 0x4024EA: main (stack.c:695) ==55019== Address 0x6026000 is not stack'd, malloc'd or (recently) free'd ==55019== ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28659] UBSan seems to complain about an "integer overflow" in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28659 --- Comment #4 from Evgeny Vereshchagin --- > But it comes with a horribly proprietary license Unfortunately LGTM (like many other CI services) is tightly coupled with GitHub (where it can be used for automated analysis of open source projects) so in theory it should be possible to keep a read-only fork of the elfutils repository updated by a cron script run by buildbot. I'm not sure whether it's worth it though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28660] ASan seems to complain about a "heap-buffer-overflow"
https://sourceware.org/bugzilla/show_bug.cgi?id=28660 --- Comment #3 from Evgeny Vereshchagin --- Looks like it keeps popping up with all the patches applied ``` 0a2c8345 libdwfl: Don't try to convert too many dyns in dwfl_link_map_report ea8ce550 libdwfl: Don't install an Elf handle in a Dwfl_Module twice 906e0ca5 libdwfl: Don't trust e_shentsize in dwfl_segment_report_module a5dc98be libdwfl: Make sure we know the phdr entry size before searching phdrs. 8ae296dc libdwfl: Add overflow check while iterating in dwfl_segment_report_module c0dd1c35 libdwfl: Don't try to convert too many bytes in dwfl_link_map_report 5ba884a5 configure: Add --enable-sanitize-address ``` I'll attach a file triggering it once the fuzz target runs into it again -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28660] ASan seems to complain about a "heap-buffer-overflow"
https://sourceware.org/bugzilla/show_bug.cgi?id=28660 --- Comment #4 from Evgeny Vereshchagin --- Created attachment 13842 --> https://sourceware.org/bugzilla/attachment.cgi?id=13842&action=edit File triggering an "invalid read" I've just attached a file triggering the issue: ``` autoreconf -i -f ./configure --enable-maintainer-mode make -j$(nproc) V=1 DEBUGINFOD_URLS= LD_PRELOAD="./libelf/libelf.so ./libdw/libdw.so" valgrind --leak-check=full ./src/stack --core ../crash-e8e47de6a28b1be30e3a7e2f92b7c9e4f4fffa9d ==87229== Memcheck, a memory error detector ==87229== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==87229== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==87229== Command: ./src/stack --core ../crash-e8e47de6a28b1be30e3a7e2f92b7c9e4f4fffa9d ==87229== ==87229== Invalid read of size 4 ==87229==at 0x48C783F: dwfl_link_map_report (link_map.c:917) ==87229==by 0x48C8DC5: dwfl_core_file_report@@ELFUTILS_0.158 (core-file.c:548) ==87229==by 0x402EC6: parse_opt (stack.c:595) ==87229==by 0x4C4D591: argp_parse (in /usr/lib64/libc.so.6) ==87229==by 0x4024EA: main (stack.c:695) ==87229== Address 0x5029ae0 is 0 bytes after a block of size 4,096 alloc'd ==87229==at 0x484186F: malloc (vg_replace_malloc.c:381) ==87229==by 0x48C7D6B: dwfl_link_map_report (link_map.c:891) ==87229==by 0x48C8DC5: dwfl_core_file_report@@ELFUTILS_0.158 (core-file.c:548) ==87229==by 0x402EC6: parse_opt (stack.c:595) ==87229==by 0x4C4D591: argp_parse (in /usr/lib64/libc.so.6) ==87229==by 0x4024EA: main (stack.c:695) ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28677] Bad dynamic entry conversion in dwfl_link_map_report
https://sourceware.org/bugzilla/show_bug.cgi?id=28677 Evgeny Vereshchagin changed: What|Removed |Added CC||evvers at ya dot ru --- Comment #2 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #1) > Proposed patch: > https://sourceware.org/pipermail/elfutils-devel/2021q4/004507.html With that patch applied I can no longer reproduce the issue. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
Bug ID: 28685
Summary: UBSan: member access within misaligned address
0x7ff316818032 for type 'struct Elf32_Phdr'
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libelf
Assignee: unassigned at sourceware dot org
Reporter: evvers at ya dot ru
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Created attachment 13845
--> https://sourceware.org/bugzilla/attachment.cgi?id=13845&action=edit
File triggering an "alignment" check
Trying to integrate the fuzz target into the test suite in
https://github.com/evverx/elfutils/pull/49, I noticed that it triggered the
"alignment" check in both gcc and clang (which I think is a bug because
`--enable-sanitize-undefined` explicitly turns off misaligned access). It can
be reproduced by building elfutils with UBSan and passing the attachment to
`./src/stack`:
```
autoreconf -i -f
./configure --enable-maintainer-mode --enable-sanitize-undefined CFLAGS='-g -O1
-fno-omit-frame-pointer' CXXFLAGS='-g -O1 -fno-omit-frame-pointer'
make -j$(nproc) V=1
UBSAN_OPTIONS=print_stacktrace=1:print_summary=1
LD_LIBRARY_PATH="./libelf:./libdw" ./src/stack --core ../oss-fuzz-41575
$ UBSAN_OPTIONS=print_stacktrace=1:print_summary=1
LD_LIBRARY_PATH="./libelf:./libdw" ./src/stack --core ../oss-fuzz-41575
gelf_xlate.h:42:1: runtime error: member access within misaligned address
0x7f019ba78032 for type 'struct Elf32_Phdr', which requires 4 byte alignment
0x7f019ba78032: note: pointer points here
2b 00 48 00 00 00 00 10 00 ff ff 7f 45 4c 46 01 01 01 0c 00 ff 00 00 00 00
00 00 04 00 3e ff 00
^
#0 0x7f019d8fa5ea in Elf32_cvt_Phdr
/home/vagrant/elfutils/libelf/gelf_xlate.h:42
#1 0x7f019d8f85f3 in elf32_xlatetom
/home/vagrant/elfutils/libelf/elf32_xlatetom.c:104
#2 0x7f019d827a76 in dwfl_segment_report_module
/home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:472
#3 0x7f019d82c6db in _new.dwfl_core_file_report
/home/vagrant/elfutils/libdwfl/core-file.c:559
#4 0x402b0f in parse_opt /home/vagrant/elfutils/src/stack.c:595
#5 0x7f019ca7d471 in argp_parse (/lib64/libc.so.6+0x11e471)
#6 0x403d98 in main /home/vagrant/elfutils/src/stack.c:695
#7 0x7f019c98c55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#8 0x7f019c98c60b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b)
#9 0x4024c4 in _start (/home/vagrant/elfutils/src/stack+0x4024c4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gelf_xlate.h:42:1 in
```
Interestingly, judging by
https://copr-be.cloud.fedoraproject.org/results/packit/evverx-elfutils-49/fedora-rawhide-i386/03030724-elfutils/builder-live.log.gz
(where I ran the unit tests on i386) the file simply crashed the fuzz target
there
```
FAIL: run-fuzz-dwfl-core.sh
===
...
StandaloneFuzzTargetMain: running 1 inputs
Running:
/builddir/build/BUILD/elfutils-0.186/tests/fuzz-dwfl-core-corpus/oss-fuzz-41575
timeout: the monitored command dumped core
./test-subr.sh: line 84: 20674 Segmentation fault
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
*** failure in
/builddir/build/BUILD/elfutils-0.186/tests/fuzz-dwfl-core-corpus/oss-fuzz-41575
FAIL run-fuzz-dwfl-core.sh (exit status: 1)
+ false
error: Bad exit status from /var/tmp/rpm-tmp.P3WRAR (%check)
```
On OSS-Fuzz (on x86_64) that file triggered an "oom" reported in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41575
```
Running:
/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/oom-fa37b37eafe95a0ed4ef155ccb7f8178f177061d
==9982== ERROR: libFuzzer: out-of-memory (malloc(4294971391))
To change the out-of-memory limit use -rss_limit_mb=
#0 0x52f411 in __sanitizer_print_stack_trace
/src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:87:3
#1 0x470a38 in fuzzer::PrintStackTrace() cxa_noexception.cpp:0
#2 0x454bb5 in fuzzer::Fuzzer::HandleMalloc(unsigned long)
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:131:3
#3 0x454aca in fuzzer::MallocHook(void const volatile*, unsigned long)
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:100:6
#4 0x536a37 in __sanitizer::RunMallocHooks(void const*, unsigned long)
/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common.cpp:308:5
#5 0x4a6388 in __asan::Allocator::Allocate(unsigned long, unsigned long,
__sanitizer::BufferedStackTrace*, __asan::AllocType, bool)
/src/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:611:5
#6 0x4a6549 in Calloc
/src/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:748:17
#7 0x4a6549 in __asan::asan_calloc(unsigned long, unsigned long,
__sanitizer::Buffered
[Bug libdw/28660] ASan seems to complain about a "heap-buffer-overflow"
https://sourceware.org/bugzilla/show_bug.cgi?id=28660 --- Comment #6 from Evgeny Vereshchagin --- Thanks! I can confirm that the issue is gone. I tested it in https://github.com/evverx/elfutils/pull/53 by adding that file to the testsuite in https://github.com/evverx/elfutils/pull/53/commits/38c241bf6269ab5a1dd93b606e11001dc3b6c1f4. I also ran the fuzzer for about 10 minutes. Interestingly, something started to trigger unreproducible MSan crashes but I'm inclined to say it was probably a fluke. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28660] ASan seems to complain about a "heap-buffer-overflow"
https://sourceware.org/bugzilla/show_bug.cgi?id=28660 --- Comment #7 from Evgeny Vereshchagin --- > Interestingly, something started to trigger unreproducible MSan crashes but > I'm inclined to say it was probably a fluke. It wasn't a glitch. The file I added to the test suite was also automatically added to the seed corpus, which in turn triggered new code paths and led to large allocations I reported elsewhere. So it doesn't have anything to do with this issue and the patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28708] New: run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 Bug ID: 28708 Summary: run-debuginfod-webapi-concurrency.sh seems to be flaky Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- elfutils is built on various architectures with https://packit.dev/ in https://github.com/evverx/elfutils and since run-debuginfod-webapi-concurrency.sh was added it has been failing more or less consistently on ppc64le and intermittently on the other architectures. The log can be found at https://copr-be.cloud.fedoraproject.org/results/packit/evverx-elfutils-53/fedora-rawhide-ppc64le/03059293-elfutils/builder-live.log.gz. It will expire eventually though but as far as I can see it's reported by buildbot from time to time as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 --- Comment #1 from Evgeny Vereshchagin --- Created attachment 13859 --> https://sourceware.org/bugzilla/attachment.cgi?id=13859&action=edit full log Just in case, I've just attached the full log. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 --- Comment #3 from Evgeny Vereshchagin --- I think they are constrained in the sense that those machines are much slower than usual. On top of that the packages are built in a sandbox environment and that makes them even slower. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685 --- Comment #2 from Evgeny Vereshchagin --- > Should we try to handle unaligned access in the xlateto functions? > Those functions make use of a lot of tricky macros, which depend on the > types passed in. > > Or should we fix the called (dwfl_segment_report_module) to only pass > correctly aligned buffers to the xlateto function? > I think it depends on how libelf is supposed to be used. If callers are expected to pass correctly aligned buffers it seems dwfl_segment_report_module should be fixed. But it seems that callers can sometimes assume that it should be fine to pass unaligned data. For example, (even though it has nothing to do with the xlateto functions) in one of libbpf issues it was pointed out that "I don't see anywhere the requirement that bytes passed to the elf_memory() should be aligned, so this does seem like libelf bug." -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28710] New: ERROR: AddressSanitizer: SEGV on unknown address (on i386)
https://sourceware.org/bugzilla/show_bug.cgi?id=28710 Bug ID: 28710 Summary: ERROR: AddressSanitizer: SEGV on unknown address (on i386) Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13861 --> https://sourceware.org/bugzilla/attachment.cgi?id=13861&action=edit File triggering ASan OSS-Fuzz reported a stack-use-after-return on i386 in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42264. It can be reproduced on an x86_64 Fedora machine by installing libc.i686, zlib-devel.i686 and libasan.i686 and building elfutils with -m32 ``` autoreconf -i -f ./configure --enable-maintainer-mode --disable-debuginfod --disable-libdebuginfod --without-bzlib --without-lzma --without-zstd --enable-sanitize-address CFLAGS="-m32 -g -O1" CXXFLAGS="-m32 -g -O1" make -j$(nproc) V=1 $ ASAN_OPTIONS=detect_stack_use_after_return=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core ./oss-fuzz-42264 = ==13653==ERROR: AddressSanitizer: stack-use-after-return on address 0xf567a000 at pc 0xf7860e9b bp 0xffc10ae8 sp 0xffc10adc READ of size 4 at 0xf567a000 thread T0 #0 0xf7860e9a in dwfl_segment_report_module /home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:556 #1 0xf786e251 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:559 #2 0x804b78a in parse_opt /home/vagrant/elfutils/src/stack.c:595 #3 0xf7457d4d in argp_parse (/lib/libc.so.6+0x11ed4d) #4 0x804caaa in main /home/vagrant/elfutils/src/stack.c:695 #5 0xf735e468 in __libc_start_call_main (/lib/libc.so.6+0x25468) #6 0xf735e549 in __libc_start_main_impl (/lib/libc.so.6+0x25549) #7 0x804a57b in _start (/home/vagrant/elfutils/src/stack+0x804a57b) Address 0xf567a000 is located in stack of thread T0 at offset 0 in frame #0 0xf786d0ef in dwfl_report_core_segments /home/vagrant/elfutils/libdwfl/core-file.c:126 This frame has 1 object(s): [32, 88) 'phdr_mem' (line 137) ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28715] New: There seems to be an infinite loop in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28715 Bug ID: 28715 Summary: There seems to be an infinite loop in dwfl_segment_report_module Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13863 --> https://sourceware.org/bugzilla/attachment.cgi?id=13863&action=edit File causing an infinite loop It was reported today in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42645 . It can be reproduced with `./src/stack`: ``` autoreconf -i -f ./configure --enable-maintainer-mode make -j$(nproc) V=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core ../oss-fuzz-42645 ``` According to eu-stack it's in dwfl_segment_report_module ``` PID 212089 - process TID 212089: #0 0x7f6af3447cd5 dwfl_segment_report_module #1 0x7f6af344bf88 dwfl_core_file_report@@ELFUTILS_0.158 #2 0x00402ec7 parse_opt #3 0x7f6af30da472 argp_parse #4 0x004024eb main #5 0x7f6af2fe9560 __libc_start_call_main #6 0x7f6af2fe960c __libc_start_main@@GLIBC_2.34 #7 0x00402725 _start ``` Below is the backtrace OSS-Fuzz attached to the issue (with line numbers): ``` ALARM: working on the last Unit for 61 seconds and the timeout value is 60 (use -timeout=N to change) ==822== ERROR: libFuzzer: timeout after 61 seconds #0 0x4b22d4 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/ubsan/ubsan_diag_standalone.cpp:31:3 #1 0x457438 in fuzzer::PrintStackTrace() cxa_noexception.cpp:0 #2 0x43c329 in fuzzer::Fuzzer::AlarmCallback() cxa_noexception.cpp:0 #3 0x7f1be648c3bf in libpthread.so.0 #4 0x4aea5b in atomic_exchange<__sanitizer::atomic_uint32_t> /src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h:67:7 #5 0x4aea5b in acquire /src/llvm-project/compiler-rt/lib/ubsan/ubsan_value.h:60:21 #6 0x4aea5b in handleNegateOverflowImpl(__ubsan::OverflowData*, unsigned long, __ubsan::ReportOptions) /src/llvm-project/compiler-rt/lib/ubsan/ubsan_handlers.cpp:251:34 #7 0x4aea2d in __ubsan_handle_negate_overflow /src/llvm-project/compiler-rt/lib/ubsan/ubsan_handlers.cpp:277:3 #8 0x517854 in dwfl_segment_report_module /src/elfutils/libdwfl/dwfl_segment_report_module.c:581:58 #9 0x4b8937 in dwfl_core_file_report /src/elfutils/libdwfl/core-file.c:559:17 #10 0x4b388e in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6 #11 0x43d953 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp:0 #12 0x429592 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #13 0x42edec in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp:0 #14 0x457bf2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #15 0x7f1be62800b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 #16 0x407d4d in _start ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 --- Comment #7 from Evgeny Vereshchagin --- > Note that packit doesn't use real hardware for various architectures but > "container emulation" which causes various testcases to fail. > I think I ran into issues like that in https://github.com/evverx/elfutils/issues/32 and https://github.com/evverx/elfutils/issues/31. I ignore them for the most part. Though it would be great if they could be skipped there. Some of them seem to be easy to skip because they seem to trigger seccomp filters of some kind but I'm not sure about the rest. > Although in this case it seems it is overloading the host. Maybe we can tune > down the number of concurrent request tested, see also: > https://sourceware.org/pipermail/elfutils-devel/2021q4/thread.html#4488 > If you have a better lower/upper bound or a way to test the limits of the > machine. > Thanks for the link. I'll take a look. > We do have somewhat better buildbot workers for various architectures here: > https://builder.wildebeest.org/buildbot/#/builders?tags=elfutils As far as I understand the tests are run there on commits to the elfutils repository but I'm not sure how to test "PRs" there. If it was possible to use it before commits are merged into the master branch I wouldn't have started using Packit on GitHub probably. > Is there some way of finding out the host's actual limits? Can we detect that > we're running in an unusually constricted environment and skip this test > ulimit -u? I think I can run almost anything there but since I'm not familiar with the test I'm not sure what I should look for. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28715] There seems to be an infinite loop in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28715 --- Comment #2 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #1) > I couldn't replicate the infinite loop, which I assume has been fixed by: > https://sourceware.org/pipermail/elfutils-devel/2021q4/004557.html > > But I saw it did trigger yet another xlate alignment issue for which I did > submit: > https://sourceware.org/pipermail/elfutils-devel/2021q4/004565.html Thanks! I'll try to take a look tomorrow. There seem to be quite a few new patches on the mailing list. I wonder if it's possible to somehow fetch a branch with all of them so that I could just rebase the fuzzing infrastructure on top of it? > P.S. Note that the bugs.chromium.org link doesn't work for me, it apparently > requires a google account with permissions to even just look at that bug. It's possible to make all the bug reports public by default. For example, in https://github.com/google/oss-fuzz/pull/6741 the PHP project decided that bug reports should be no longer restricted and flipped the flag. I can do the same but I don't think I can do it without your approval. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685 --- Comment #4 from Evgeny Vereshchagin --- I can confirm that with those three patches applied I can no longer reproduce the issue. I tested it with both `--enable-honggfuzz` from https://sourceware.org/pipermail/elfutils-devel/2021q4/004554.html and with CFlite (which ran the fuzzer for 10 minutes under UBSan) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28715] There seems to be an infinite loop in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28715 --- Comment #3 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #1) > I couldn't replicate the infinite loop, which I assume has been fixed by: > https://sourceware.org/pipermail/elfutils-devel/2021q4/004557.html I haven't backported that patch yet but as far as I can see the infinite loop can't be triggered with the following patches applied: ``` afd19a71 libdwfl: Handle unaligned Phdr in dwfl_segment_report_module cf41ae95 libdwfl: Handle unaligned Ehdr in dwfl_segment_report_module 7f5e5da8 libdwfl: Make sure note data is properly aligned. ``` > But I saw it did trigger yet another xlate alignment issue for which I did > submit: > https://sourceware.org/pipermail/elfutils-devel/2021q4/004565.html I've just ran into that as well. I'll apply the patch and report back if it's still there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685 --- Comment #5 from Evgeny Vereshchagin --- Created attachment 13867 --> https://sourceware.org/bugzilla/attachment.cgi?id=13867&action=edit regression I ran the fuzzer a bit longer and it seems https://sourceware.org/pipermail/elfutils-devel/2021q4/004562.html introduced a regression: ``` $ LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core ../crash-83c981b28f378121157262f840b36f1ba7089a21 = ==323325==ERROR: AddressSanitizer: unknown-crash on address 0x7f54aacd7000 at pc 0x004c3efa bp 0x7ffd969da5b0 sp 0x7ffd969d9d60 READ of size 2097120 at 0x7f54aacd7000 thread T0 #0 0x4c3ef9 in __asan_memcpy (/home/vagrant/elfutils/src/stack+0x4c3ef9) #1 0x7f54ac1b21f4 in memcpy /usr/include/bits/string_fortified.h:29:10 #2 0x7f54ac1b21f4 in dwfl_segment_report_module /home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:466:7 #3 0x7f54ac1c09f8 in dwfl_core_file_report@@ELFUTILS_0.158 /home/vagrant/elfutils/libdwfl/core-file.c:559:17 #4 0x4fe447 in parse_opt /home/vagrant/elfutils/src/stack.c:595:8 #5 0x7f54abbcb471 in argp_parse (/lib64/libc.so.6+0x11e471) #6 0x4fd99d in main /home/vagrant/elfutils/src/stack.c:695:3 #7 0x7f54abada55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #8 0x7f54abada60b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b) #9 0x41d6c4 in _start (/home/vagrant/elfutils/src/stack+0x41d6c4) Address 0x7f54aacd7000 is a wild pointer inside of access range of size 0x001fffe0. SUMMARY: AddressSanitizer: unknown-crash (/home/vagrant/elfutils/src/stack+0x4c3ef9) in __asan_memcpy Shadow bytes around the buggy address: 0x0feb15592db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0feb15592dc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0feb15592dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0feb15592de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0feb15592df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0feb15592e00:[fe]fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe 0x0feb15592e10: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe 0x0feb15592e20: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe 0x0feb15592e30: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe 0x0feb15592e40: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe 0x0feb15592e50: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==323325==ABORTING ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28715] There seems to be an infinite loop in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28715
--- Comment #4 from Evgeny Vereshchagin ---
(In reply to Evgeny Vereshchagin from comment #3)
> (In reply to Mark Wielaard from comment #1)
> > I couldn't replicate the infinite loop, which I assume has been fixed by:
> > https://sourceware.org/pipermail/elfutils-devel/2021q4/004557.html
>
> I haven't backported that patch yet but as far as I can see the infinite
> loop can't be triggered with the following patches applied:
> ```
> afd19a71 libdwfl: Handle unaligned Phdr in dwfl_segment_report_module
> cf41ae95 libdwfl: Handle unaligned Ehdr in dwfl_segment_report_module
> 7f5e5da8 libdwfl: Make sure note data is properly aligned.
> ```
Looks like I was wrong. Packit along with run-fuzz-dwfl-core.sh actually caught
the infinite loop on 32 bit platforms:
```
Running:
/builddir/build/BUILD/elfutils-0.186/tests/fuzz-dwfl-core-crashes/oss-fuzz-42645
./test-subr.sh: line 84: 20115 Killed
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
```
I just didn't wait for it to finish.
I'll try to apply
https://sourceware.org/pipermail/elfutils-devel/2021q4/004557.html shortly and
report back.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/28715] There seems to be an infinite loop in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28715 --- Comment #5 from Evgeny Vereshchagin --- I can't seem to apply that patch: ``` $ git am --exclude=libdwfl/ChangeLog p4.patch Applying: libdwfl: Rewrite GElf_Nhdr reading in dwfl_segment_report_module error: patch failed: libdwfl/dwfl_segment_report_module.c:552 error: libdwfl/dwfl_segment_report_module.c: patch does not apply Patch failed at 0001 libdwfl: Rewrite GElf_Nhdr reading in dwfl_segment_report_module ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685 --- Comment #7 from Evgeny Vereshchagin --- Created attachment 13869 --> https://sourceware.org/bugzilla/attachment.cgi?id=13869&action=edit archive with a report and a file triggering a memory leak Thanks! That branch helped me a lot. I rebased it on top of my "fuzz" branch and pushed it to trigger the tests. CFLite reported a memory leak: ``` $ DEBUGINFOD_URLS= LD_LIBRARY_PATH="./libdw;./libelf" valgrind --leak-check=full ./src/stack --core ./MEMLEAK/address/leak-8cd1af3e2ba6f343794fbee7232b1531695d2ab1 ==379530== Memcheck, a memory error detector ==379530== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==379530== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==379530== Command: ./src/stack --core ./MEMLEAK/address/leak-8cd1af3e2ba6f343794fbee7232b1531695d2ab1 ==379530== PID 1147239 - core TID 1147239: #0 0x55dea11b3135 ./src/stack: dwfl_thread_getframes tid 1147239 at 0x55dea11b3135 in : invalid operation ==379530== ==379530== HEAP SUMMARY: ==379530== in use at exit: 37,280 bytes in 97 blocks ==379530== total heap usage: 4,597 allocs, 4,500 frees, 302,708 bytes allocated ==379530== ==379530== 20 bytes in 1 blocks are definitely lost in loss record 1 of 8 ==379530==at 0x484186F: malloc (vg_replace_malloc.c:381) ==379530==by 0x48C4E15: dwfl_segment_report_module (dwfl_segment_report_module.c:632) ==379530==by 0x48C8F3E: dwfl_core_file_report@@ELFUTILS_0.158 (core-file.c:559) ==379530==by 0x402EC6: parse_opt (stack.c:595) ==379530==by 0x4C4E471: argp_parse (in /usr/lib64/libc.so.6) ==379530==by 0x4024EA: main (stack.c:695) ==379530== ==379530== LEAK SUMMARY: ==379530==definitely lost: 20 bytes in 1 blocks ==379530==indirectly lost: 0 bytes in 0 blocks ==379530== possibly lost: 0 bytes in 0 blocks ==379530==still reachable: 37,260 bytes in 96 blocks ==379530== suppressed: 0 bytes in 0 blocks ==379530== Reachable blocks (those to which a pointer was found) are not shown. ==379530== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==379530== ==379530== For lists of detected and suppressed errors, rerun with: -s ==379530== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ``` I haven't tested it with the files that triggered the regression I mentioned at https://sourceware.org/bugzilla/show_bug.cgi?id=28685#c5 . I'll put those files to the "seed" corpus and report back. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28710] ERROR: AddressSanitizer: SEGV on unknown address (on i386)
https://sourceware.org/bugzilla/show_bug.cgi?id=28710 --- Comment #2 from Evgeny Vereshchagin --- With https://code.wildebeest.org/git/user/mjw/elfutils/log/?h=fuzz rebased on top of my "fuzzing" branch I can no longer reproduce this issue. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28715] There seems to be an infinite loop in dwfl_segment_report_module
https://sourceware.org/bugzilla/show_bug.cgi?id=28715 --- Comment #8 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #7) > (In reply to Evgeny Vereshchagin from comment #2) > > There seem to be quite a few new patches on the mailing list. I wonder if > > it's possible to somehow fetch a branch with all of them so that I could > > just rebase the fuzzing infrastructure on top of it? > > All patches sent to the list are also in patchwork: > https://patchwork.sourceware.org/project/elfutils/list/ > > I keep work in progress also in branch in my own git tree: > https://code.wildebeest.org/git/user/mjw/elfutils/ > > The fuzz branch has all recent patches based on your fuzzing reports and my > own finds running afl and afl++ on amd64 and i686 for eu-stack --core > With https://code.wildebeest.org/git/user/mjw/elfutils/log/?h=fuzz rebased on top of my "fuzzing" branch I can no longer reproduce this issue. Thanks! > I think it is better if the reports were public. Got it. I'll flip the flag there then. Would it be OK if I added your email address to https://github.com/google/oss-fuzz/blob/master/projects/elfutils/project.yaml so that you could be notified when new bug reports were opened? > But I think google really > should just report these issues upstream instead of hiding them in their own > bug tracker. Unfortunately I can't change that (and I'm not affiliated with Google in any way). I tried to use my main email address there but at some point I had to create a gmail account to be able to look at systemd bug reports. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685 --- Comment #8 from Evgeny Vereshchagin --- I can't reproduce that "unknown-crash on address 0x7f54aacd7000" anymore. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 --- Comment #10 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #9) > (In reply to Evgeny Vereshchagin from comment #7) > > > Note that packit doesn't use real hardware for various architectures but > > > "container emulation" which causes various testcases to fail. > > > > > I think I ran into issues like that in > > https://github.com/evverx/elfutils/issues/32 and > > https://github.com/evverx/elfutils/issues/31. I ignore them for the most > > part. Though it would be great if they could be skipped there. Some of them > > seem to be easy to skip because they seem to trigger seccomp filters of some > > kind but I'm not sure about the rest. > > Easiest is to run containers with --security-opt seccomp=unconfined to make > sure seccomp doesn't arbitrarily blocks syscalls (or worse returns ENOPERM > instead on ENOSYS). > Those containers are launched by Packit (or, more precisely, by mock) so I can't control how they are run. According to systemd-detect --virt those are nspawn containers and I'm 50% sure those failures are caused by a bug in either systemd-nspawn or libseccomp. In the meantime, I added a couple of bash commands that show whether the test hit its "pid" limit set by either systemd on the host or systemd-nspawn (or both). pid.max is unfortunately set to "max" there so it isn't obvious how many tasks can be run there at the same time. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685 --- Comment #10 from Evgeny Vereshchagin --- Looks like the memory leak is gone. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] New: UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 Bug ID: 28720 Summary: UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13872 --> https://sourceware.org/bugzilla/attachment.cgi?id=13872&action=edit File triggering misaligned access While I was testing https://sourceware.org/pipermail/elfutils-devel/2021q4/004584.html I passed FUZZ_TIME=3600 to the test to run it for an hour and in the process it ran into another misaligned access. Just to make sure it isn't https://sourceware.org/bugzilla/show_bug.cgi?id=28685 I pulled the master branch with the "fuzz" branch included. It can be reproduced with `./src/stack`: ``` autoreconf -i -f ./configure --enable-maintainer-mode --enable-sanitize-undefined make -j$(nproc) V=1 UBSAN_OPTIONS=print_stacktrace=1:print_summary=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core ../SIGABRT.PC.7fffe516d84c.STACK.d7ffe76d7.CODE.-6.ADDR.0.INSTR.mov%eax,%ebp.fuzz gelf_xlate.h:42:1: runtime error: member access within misaligned address 0x7f3827783142 for type 'struct Elf32_Phdr', which requires 4 byte alignment 0x7f3827783142: note: pointer points here 00 00 00 10 00 00 00 00 00 c5 00 10 00 00 00 00 00 00 00 10 00 00 00 00 00 00 01 00 00 00 06 15 ^ #0 0x7f38295f992c in Elf32_cvt_Phdr /home/vagrant/elfutils/libelf/gelf_xlate.h:42 #1 0x7f38295f8363 in elf32_xlatetom /home/vagrant/elfutils/libelf/elf32_xlatetom.c:104 #2 0x7f382952a821 in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:925 #3 0x7f382952de80 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:548 #4 0x402fa0 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #5 0x7f382878b471 in argp_parse (/lib64/libc.so.6+0x11e471) #6 0x4026aa in main /home/vagrant/elfutils/src/stack.c:695 #7 0x7f382869a55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #8 0x7f382869a60b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b) #9 0x402944 in _start (/home/vagrant/elfutils/src/stack+0x402944) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gelf_xlate.h:42:1 in ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #1 from Evgeny Vereshchagin --- FWIW There are at least 4 uniq crashes honggfuzz has found related to either "member access within misaligned address" or "load of misaligned address": gelf_xlate.h:42:1: runtime error: member access within misaligned address link_map.c:292:15: runtime error: load of misaligned address 0x7fffe5c60bde for type 'Elf64_Addr' link_map.c:283:15: runtime error: load of misaligned address gelf_xlate.h:48:1: runtime error: member access within misaligned address -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #3 from Evgeny Vereshchagin --- As far as I can see with the fuzz branch rebased on top on my fuzzing branch almost all the issues including https://sourceware.org/pipermail/elfutils-devel/2021q4/004596.html are gone. Thanks! I'll attach files triggering the remaining issues shortly: ``` $ UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core SIGABRT.PC.7fffe4f4e84c.STACK.18f0f46b60.CODE.-6.ADDR.0.INSTR.mov%eax,%ebp.fuzz link_map.c:1040:20: runtime error: variable length array bound evaluates to non-positive value 0 #0 0x7fbc58f053e9 in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:1040 #1 0x7fbc59023fa7 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:552 #2 0x4053f7 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #3 0x7fbc581d9471 in argp_parse (/lib64/libc.so.6+0x11e471) #4 0x404b39 in main /home/vagrant/elfutils/src/stack.c:695 #5 0x7fbc580e855f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #6 0x7fbc580e860b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b) #7 0x404fa4 in _start (/home/vagrant/elfutils/src/stack+0x404fa4) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior link_map.c:1040:20 in ``` ``` $ UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core SIGABRT.PC.7fffe4f4e84c.STACK.1976b2f3ff.CODE.-6.ADDR.0.INSTR.mov%eax,%ebp.fuzz gelf_xlate.h:48:1: runtime error: member access within misaligned address 0x7f0817719077 for type 'struct Elf32_Dyn', which requires 4 byte alignment 0x7f0817719077: note: pointer points here 00 10 00 00 00 00 00 00 00 00 02 01 00 00 00 00 00 00 7f 45 46 4c 46 00 00 01 01 00 01 00 08 00 ^ #0 0x7f0822689542 in Elf32_cvt_Dyn /home/vagrant/elfutils/libelf/gelf_xlate.h:48 #1 0x7f082268835e in elf32_xlatetom /home/vagrant/elfutils/libelf/elf32_xlatetom.c:104 #2 0x7f0819563307 in dwfl_segment_report_module /home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:848 #3 0x7f081956c06c in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:563 #4 0x4053f7 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #5 0x7f0818721471 in argp_parse (/lib64/libc.so.6+0x11e471) #6 0x404b39 in main /home/vagrant/elfutils/src/stack.c:695 #7 0x7f081863055f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #8 0x7f081863060b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b) #9 0x404fa4 in _start (/home/vagrant/elfutils/src/stack+0x404fa4) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gelf_xlate.h:48:1 in ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #4 from Evgeny Vereshchagin --- Created attachment 13874 --> https://sourceware.org/bugzilla/attachment.cgi?id=13874&action=edit File triggering "variable length array bound evaluates to non-positive value 0" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #5 from Evgeny Vereshchagin --- Created attachment 13875 --> https://sourceware.org/bugzilla/attachment.cgi?id=13875&action=edit File triggering "member access within misaligned address" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #6 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #2) > Interesting. I did run afl for some time (more than a day) and it found some > more issues, but none of these (yet?). I'll try honggfuzz in the future to > see if it can find some more. > FWIW https://sourceware.org/pipermail/elfutils-devel/2021q4/004584.html should make it much more easier to use honggfuzz. It's safe to say that it was battle-tested in the sense that it's compatible with gcc, clang, ASan, UBsan and so on. Something like `make check V=1 VERBOSE=1 TESTS=run-fuzz-dwfl-core.sh FUZZ_TIME=3600` allows running the fuzz target for an hour with honggfuzz (if elfutils is built with `--enable-honggfuzz`) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #8 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #7) > commit 9f70a762ab88ceebb8a48a7c9c3ce39ff7f205af > Author: Mark Wielaard > Date: Fri Dec 24 02:01:32 2021 +0100 > > libdwfl: Calculate addr to read by hand in link_map.c read_addrs. > > The gcc undefined sanitizer doesn't like the trick we use to calculate > the (possibly) unaligned addresses to read. So calculate them by hand > as unsigned char pointers. > > https://sourceware.org/bugzilla/show_bug.cgi?id=28720 > > Signed-off-by: Mark Wielaard > > Which should this particular issue. I'm not sure but it seems it can still be triggered with that commit applied: ``` $ git log --oneline -5 9f70a762 (HEAD -> master, origin/master, origin/HEAD) libdwfl: Calculate addr to read by hand in link_map.c read_addrs. 5b490793 libdwfl: Call xlatetom on aligned buffers in dwfl_link_map_report 1cf73965 libdwfl: Make sure dwfl_elf_phdr_memory_callback returns at least minread 4fdd8588 libdwfl: Always clean up build_id.memory 8f8c78cc libdwfl: Handle unaligned Nhdr in dwfl_segment_report_module $ autoreconf -i -f $ ./configure --enable-maintainer-mode --enable-sanitize-undefined $ make -j$(nproc) V=1 $ UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core ./attachment.cgi\?id\=13875 gelf_xlate.h:48:1: runtime error: member access within misaligned address 0x7f5cd5612077 for type 'struct Elf32_Dyn', which requires 4 byte alignment 0x7f5cd5612077: note: pointer points here 00 10 00 00 00 00 00 00 00 00 02 01 00 00 00 00 00 00 7f 45 46 4c 46 00 00 01 01 00 01 00 08 00 ^ #0 0x7f5cd74851fc in Elf32_cvt_Dyn /home/vagrant/elfutils/libelf/gelf_xlate.h:48 #1 0x7f5cd7484363 in elf32_xlatetom /home/vagrant/elfutils/libelf/elf32_xlatetom.c:104 #2 0x7f5cd73b4fbf in dwfl_segment_report_module /home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:848 #3 0x7f5cd73b9fc9 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:563 #4 0x402fa0 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #5 0x7f5cd6617471 in argp_parse (/lib64/libc.so.6+0x11e471) #6 0x4026aa in main /home/vagrant/elfutils/src/stack.c:695 #7 0x7f5cd652655f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #8 0x7f5cd652660b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b) #9 0x402944 in _start (/home/vagrant/elfutils/src/stack+0x402944) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gelf_xlate.h:48:1 in ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #9 from Evgeny Vereshchagin --- According to OSS-Fuzz looks like that commit triggered https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43307 (which was also reported in https://sourceware.org/pipermail/elfutils-devel/2022q1/004623.html): ``` $ wget -O CRASH 'https://oss-fuzz.com/download?testcase_id=4696722113167360' $ LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core ./CRASH AddressSanitizer:DEADLYSIGNAL = ==153072==ERROR: AddressSanitizer: SEGV on unknown address 0x7fbe8640afe0 (pc 0x7fbe89eb2fc7 bp 0x7fffe2855510 sp 0x7fffe2855020 T0) ==153072==The signal is caused by a READ memory access. #0 0x7fbe89eb2fc7 in __bswap_64 /usr/include/bits/byteswap.h:73 #1 0x7fbe89eb2fc7 in read_addrs /home/vagrant/elfutils/libdwfl/link_map.c:288 #2 0x7fbe89eb2fc7 in report_r_debug /home/vagrant/elfutils/libdwfl/link_map.c:341 #3 0x7fbe89eb2fc7 in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:1117 #4 0x7fbe89eb7103 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:552 #5 0x403d06 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #6 0x7fbe89a90471 in argp_parse (/lib64/libc.so.6+0x11e471) #7 0x40281d in main /home/vagrant/elfutils/src/stack.c:695 #8 0x7fbe8999f55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #9 0x7fbe8999f60b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b) #10 0x402c94 in _start (/home/vagrant/elfutils/src/stack+0x402c94) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /usr/include/bits/byteswap.h:73 in __bswap_64 ==153072==ABORTING ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #11 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #10) > That is a different issue than the one reported in comment #5. > This bug might be split up for the different issues found. Sorry. I seem to have overlooked that. I think this issue can be closed then. In the meantime, I've just opened https://github.com/google/oss-fuzz/pull/7092 (which should help to start catching issues like that on OSS-Fuzz). It'll sort out duplicates automatically so I'd just wait for it to report what's left. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 Evgeny Vereshchagin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Evgeny Vereshchagin --- Forgot to close the issue. As far as I can see there are two issues left. They were reported in https://sourceware.org/pipermail/elfutils-devel/2022q1/004623.html and https://sourceware.org/pipermail/elfutils-devel/2022q1/004629.html Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #16 from Evgeny Vereshchagin --- I tested both patches with CFLite, AFL++ and hongfuzz for about ten minutes under ASan/UBSan with the reproducer testcases included in the "seed" corpus. I also unleashed the latest corpus provided by OSS-Fuzz on the fuzzer and it found nothing. Looks like both issues are gone for good. Thanks! FWIW I recently posted patch v4 where AFL/AFL++ is supported as well. I think with both `--enable-honggfuzz` and `--enable-afl` it should be possible to integrate it into buildboot smoothly. The patch can be found at https://patchwork.sourceware.org/project/elfutils/patch/20211226160323.2450838-1-evv...@ya.ru/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #17 from Evgeny Vereshchagin --- FWIW I tested https://sourceware.org/pipermail/elfutils-devel/2022q1/004637.html as well with gcc (since it isn't reproducible with clang), honggfuzz and the latest OSS-Fuzz corpus. That issue is gone too. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/29000] New: Conditional jump or move depends on uninitialised value in elf_compress_gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=29000 Bug ID: 29000 Summary: Conditional jump or move depends on uninitialised value in elf_compress_gnu Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libelf Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 14035 --> https://sourceware.org/bugzilla/attachment.cgi?id=14035&action=edit file triggering valgrind warning It was found with MSan on OSS-Fuzz but can be reproduced with Valgrind by applying https://sourceware.org/pipermail/elfutils-devel/2022q1/004767.html and running the following commands: ``` autoreconf -i -f ./configure --enable-maintainer-mode make V=1 -j$(nproc) make -C tests fuzz-libelf V=1 LD_LIBRARY_PATH="$(pwd)/libelf;$(pwd)/libdw" DEBUGINFOD_URLS= valgrind --track-origins=yes ./tests/fuzz-libelf clusterfuzz-testcase-minimized-fuzz-libelf-6467719510228992 ``` ``` unning: ../clusterfuzz-testcase-minimized-fuzz-libelf-6467719510228992 ==65519== Conditional jump or move depends on uninitialised value(s) ==65519==at 0x4868734: elf_compress_gnu (elf_compress_gnu.c:155) ==65519==by 0x401553: fuzz_logic_one (fuzz-libelf.c:41) ==65519==by 0x4016D9: LLVMFuzzerTestOneInput (fuzz-libelf.c:82) ==65519==by 0x4012B8: main (fuzz-main.c:33) ==65519== Uninitialised value was created by a heap allocation ==65519==at 0x484486F: malloc (vg_replace_malloc.c:381) ==65519==by 0x48606C6: convert_data (elf_getdata.c:168) ==65519==by 0x48606C6: __libelf_set_data_list_rdlock (elf_getdata.c:457) ==65519==by 0x48608C7: __elf_getdata_rdlock (elf_getdata.c:564) ==65519==by 0x486870A: elf_compress_gnu (elf_compress_gnu.c:150) ==65519==by 0x401553: fuzz_logic_one (fuzz-libelf.c:41) ==65519==by 0x4016D9: LLVMFuzzerTestOneInput (fuzz-libelf.c:82) ==65519==by 0x4012B8: main (fuzz-main.c:33) ==65519== Done:../clusterfuzz-testcase-minimized-fuzz-libelf-6467719510228992: (608 bytes) ==65519== ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/29000] Conditional jump or move depends on uninitialised value in elf_compress_gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=29000 --- Comment #1 from Evgeny Vereshchagin --- Created attachment 14036 --> https://sourceware.org/bugzilla/attachment.cgi?id=14036&action=edit file triggering issue in fuzz-libdwfl The same issue was found by fuzz-libdwfl. ``` make -C tests fuzz-libdwfl LD_LIBRARY_PATH="$(pwd)/libelf;$(pwd)/libdw" DEBUGINFOD_URLS= valgrind --track-origins=yes ./tests/fuzz-libdwfl ../clusterfuzz-testcase-minimized-fuzz-libdwfl-4725021634854912 ``` ``` Running: ../clusterfuzz-testcase-minimized-fuzz-libdwfl-4725021634854912 ==65641== Conditional jump or move depends on uninitialised value(s) ==65641==at 0x4868734: elf_compress_gnu (elf_compress_gnu.c:155) ==65641==by 0x489EF0E: check_section (dwarf_begin_elf.c:210) ==65641==by 0x489F6D2: global_read (dwarf_begin_elf.c:409) ==65641==by 0x489F6D2: dwarf_begin_elf (dwarf_begin_elf.c:560) ==65641==by 0x48C033C: load_dw (dwfl_module_getdwarf.c:1342) ==65641==by 0x48C0500: find_dw (dwfl_module_getdwarf.c:1392) ==65641==by 0x48C0500: dwfl_module_getdwarf (dwfl_module_getdwarf.c:1447) ==65641==by 0x401512: LLVMFuzzerTestOneInput (fuzz-libdwfl.c:45) ==65641==by 0x401248: main (fuzz-main.c:33) ==65641== Uninitialised value was created by a heap allocation ==65641==at 0x484486F: malloc (vg_replace_malloc.c:381) ==65641==by 0x48606C6: convert_data (elf_getdata.c:168) ==65641==by 0x48606C6: __libelf_set_data_list_rdlock (elf_getdata.c:457) ==65641==by 0x48608C7: __elf_getdata_rdlock (elf_getdata.c:564) ==65641==by 0x486870A: elf_compress_gnu (elf_compress_gnu.c:150) ==65641==by 0x489EF0E: check_section (dwarf_begin_elf.c:210) ==65641==by 0x489F6D2: global_read (dwarf_begin_elf.c:409) ==65641==by 0x489F6D2: dwarf_begin_elf (dwarf_begin_elf.c:560) ==65641==by 0x48C033C: load_dw (dwfl_module_getdwarf.c:1342) ==65641==by 0x48C0500: find_dw (dwfl_module_getdwarf.c:1392) ==65641==by 0x48C0500: dwfl_module_getdwarf (dwfl_module_getdwarf.c:1447) ==65641==by 0x401512: LLVMFuzzerTestOneInput (fuzz-libdwfl.c:45) ==65641==by 0x401248: main (fuzz-main.c:33) ==65641== Done:../clusterfuzz-testcase-minimized-fuzz-libdwfl-4725021634854912: (1087 bytes) ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/29000] Conditional jump or move depends on uninitialised value in elf_compress_gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=29000 --- Comment #4 from Evgeny Vereshchagin --- I rebased the "fuzz" branch on top of my fork and ran all the tests in https://github.com/evverx/elfutils/pull/73. MSan no longer complains. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 --- Comment #12 from Evgeny Vereshchagin --- FWIW with https://sourceware.org/git/?p=elfutils.git;a=commit;h=e646e363e72e06e0ed5574c929236d815ddcbbaf applied the test appears to be flaky on Packit on s390x: https://copr-be.cloud.fedoraproject.org/results/packit/evverx-elfutils-73/fedora-35-s390x/03942110-elfutils/builder-live.log.gz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29176] New: run-backtrace-native-biarch.sh seems to fail on Ubuntu Jammy
https://sourceware.org/bugzilla/show_bug.cgi?id=29176
Bug ID: 29176
Summary: run-backtrace-native-biarch.sh seems to fail on Ubuntu
Jammy
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: general
Assignee: unassigned at sourceware dot org
Reporter: evvers at ya dot ru
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
I tried to switch to Ubuntu Jammy in https://github.com/evverx/elfutils/pull/83
and the test started failing there with
```
FAIL: run-backtrace-native-biarch.sh
case 0: expected symname 'raise' got '(null)'
./test-subr.sh: line 84: 23451 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
```
It still passes on Ubuntu Focal.
FWIW switching to Ubuntu Jammy somehow "fixed"
run-debuginfod-fd-prefetch-caches.sh (which appears to be flaky on Ubuntu Focal
and fails more or less consistently when elfutils is built with --enable-gcov:
https://github.com/evverx/elfutils/runs/6577995202)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/29180] New: run-debuginfod-fd-prefetch-caches.sh seems to fail on Ubuntu Focal when elfutils is built with --enable-gcov
https://sourceware.org/bugzilla/show_bug.cgi?id=29180
Bug ID: 29180
Summary: run-debuginfod-fd-prefetch-caches.sh seems to fail on
Ubuntu Focal when elfutils is built with --enable-gcov
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: general
Assignee: unassigned at sourceware dot org
Reporter: evvers at ya dot ru
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
As far as I understand the most relevant part is
```
2022-05-25T01:03:03.3909087Z traversed_total{type="directory"} 10
2022-05-25T01:03:03.3909315Z traversed_total{type="file"} 32
2022-05-25T01:03:03.3909744Z traversed_total{type="other"} 10 =~
fdcache_prefetch_count ([0-9])+ ]]
2022-05-25T01:03:03.3910032Z + [[ 1 -ne 0 ]]
2022-05-25T01:03:03.3910197Z + err
2022-05-25T01:03:03.3910419Z + trap - ERR
2022-05-25T01:03:03.3910612Z + echo ERROR REPORTS
2022-05-25T01:03:03.3910799Z ERROR REPORTS
```
The full log can be found at
https://gist.github.com/evverx/362aa02f6ec8414d5a4f5bce59fbcd47
Since the test seems to pass on Ubuntu Jammy and Fedora Rawhide I "fixed" it by
skipping the test in https://github.com/evverx/elfutils/pull/85 and not
including it in the coverage report built on Ubuntu Focal.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/29180] run-debuginfod-fd-prefetch-caches.sh seems to fail on Ubuntu Focal when elfutils is built with --enable-gcov
https://sourceware.org/bugzilla/show_bug.cgi?id=29180 --- Comment #2 from Evgeny Vereshchagin --- With that patch applied the test passed in https://github.com/evverx/elfutils/pull/86 and according to https://coveralls.io/builds/49520251 the coverage of debuginfod.cxx went up a little. `git am` complained about trailing whitespaces ``` Applying: PR28577: Make run-debuginfod-fd-prefetch-caches.sh test something .git/rebase-apply/patch:75: trailing whitespace. kill -USR1 $PID1 .git/rebase-apply/patch:115: trailing whitespace. fi warning: 2 lines add whitespace errors. ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29176] run-backtrace-native-biarch.sh seems to fail on Ubuntu Jammy
https://sourceware.org/bugzilla/show_bug.cgi?id=29176 --- Comment #2 from Evgeny Vereshchagin --- > Do you have any more information on what changed between "Focal" and "Jammy", > glibc upgrade? some system settings, gcc upgrade? That might explain what you > are seeing? I think everything was upgraded there. As far as I can see gcc-9.4.0 was replaced with gcc-11.2.0 and glibc was upgraded from 2.31-0ubuntu9.7 to 2.35-0ubuntu3. > Best might be to add some extra printfs to tests/backtrace.c > (callback_verify) printing the frameno and framename found to see what is > going on. I'll try to do that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29176] run-backtrace-native-biarch.sh seems to fail on Ubuntu Jammy
https://sourceware.org/bugzilla/show_bug.cgi?id=29176 --- Comment #3 from Evgeny Vereshchagin --- I added printf and here's what it printed on Ubuntu Jammy: ``` FRAMENO: '0', SYMNAME: '__kernel_vsyscall' FRAMENO: '1', SYMNAME: '' FRAMENO: '2', SYMNAME: 'raise' FRAMENO: '3', SYMNAME: 'main' FRAMENO: '4', SYMNAME: '' FRAMENO: '5', SYMNAME: '__libc_start_main' FRAMENO: '6', SYMNAME: '_start' FRAMENO: '0', SYMNAME: '__kernel_vsyscall' FRAMENO: '1', SYMNAME: '' case 0: expected symname 'raise' got '(null)' ``` On Fedora 35 (where the test passes) I got ``` FRAMENO: '0', SYMNAME: '__kernel_vsyscall' FRAMENO: '1', SYMNAME: '__pthread_kill_implementation' FRAMENO: '2', SYMNAME: 'raise' FRAMENO: '3', SYMNAME: 'main' FRAMENO: '0', SYMNAME: '__kernel_vsyscall' FRAMENO: '1', SYMNAME: '__pthread_kill_implementation' FRAMENO: '2', SYMNAME: 'raise' FRAMENO: '3', SYMNAME: 'sigusr2' FRAMENO: '4', SYMNAME: 'stdarg' FRAMENO: '5', SYMNAME: 'backtracegen' FRAMENO: '6', SYMNAME: 'start' FRAMENO: '7', SYMNAME: 'start_thread' FRAMENO: '8', SYMNAME: '__clone3' FRAMENO: '0', SYMNAME: '' ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29176] run-backtrace-native-biarch.sh seems to fail on Ubuntu Jammy
https://sourceware.org/bugzilla/show_bug.cgi?id=29176 Evgeny Vereshchagin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Evgeny Vereshchagin --- Looks like it's possible to make the test pass there by installing libc6-i386-dbgsym (though I'm not sure why the test passes without that package on Focal). Anyway it doesn't seem to be an elfutils issue. I'll go ahead and close it. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29176] run-backtrace-native-biarch.sh seems to fail on Ubuntu Jammy
https://sourceware.org/bugzilla/show_bug.cgi?id=29176 --- Comment #6 from Evgeny Vereshchagin --- > Is the dbgsym package for the main (x86_64) libc6 package also installed? As far as I can see libc6-dbg is installed there but even without it when code is compiled without -m32 and aborts backtraces don't contain NULL/unknown symbols: ``` #0 0x77e25a7c in pthread_kill () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x77dd1476 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x77db77f3 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x5161 in main () ``` With -m32 and without the "x32" debug symbols backtraces look like ``` #0 0xf7fc4559 in __kernel_vsyscall () #1 0xf7e10e37 in ?? () from /lib32/libc.so.6 #2 0xf7dc04c5 in raise () from /lib32/libc.so.6 #3 0xf7da93ac in abort () from /lib32/libc.so.6 #4 0x565561b5 in main () ``` > We probably should just skip any unknown/NULL symbols. As far as I understand it should make the test pass even without the debug symbols. -- You are receiving this mail because: You are on the CC list for the bug.
