Created attachment 847774 [details] scanelf testcase scanelf -s '*' 1.crashes.elf ==58545==ERROR: AddressSanitizer: unknown-crash on address 0x7fe059136001 at pc 0x00000041bd79 bp 0x7ffe19497290 sp 0x7ffe19497288 READ of size 4 at 0x7fe059136001 thread T0 #0 0x41bd78 in scanelf_file_get_symtabs ../pax-utils-1.3.6/scanelf.c:354 #1 0x427638 in scanelf_file_sym ../pax-utils-1.3.6/scanelf.c:1313 #2 0x427638 in scanelf_elfobj ../pax-utils-1.3.6/scanelf.c:1533 #3 0x43fe33 in scanelf_elf ../pax-utils-1.3.6/scanelf.c:1598 #4 0x43fe33 in scanelf_fileat ../pax-utils-1.3.6/scanelf.c:1665 #5 0x44096c in scanelf_dirat ../pax-utils-1.3.6/scanelf.c:1699 #6 0x443e03 in scanelf_dir ../pax-utils-1.3.6/scanelf.c:1749 #7 0x443e03 in parseargs ../pax-utils-1.3.6/scanelf.c:2262 #8 0x40291e in main ../pax-utils-1.3.6/scanelf.c:2350 #9 0x7fe05caed1f6 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #10 0x7fe05caed2ab in __libc_start_main_impl ../csu/libc-start.c:381 #11 0x402c10 (/usr/bin/scanelf+0x402c10) A similar (same?) was already reported twice in the past: https://blogs.gentoo.org/ago/2017/02/01/pax-utils-scanelf-out-of-bounds-read-in-scanelf_file_get_symtabs-scanelf-c/ https://blogs.gentoo.org/ago/2017/02/25/pax-utils-scanelf-out-of-bounds-read-in-scanelf_file_get_symtabs-scanelf-c-2/
Created attachment 847882 [details] dumpelf testcase There is also a crash in dumpelf: dumpelf 1.crashes.elf ==6304==ERROR: AddressSanitizer: unknown-crash on address 0x7ff4963c7000 at pc 0x000000415aaa bp 0x7ffd1fb5c0e0 sp 0x7ffd1fb5c0d8 READ of size 4 at 0x7ff4963c7000 thread T0 #0 0x415aa9 in dump_notes ../pax-utils-1.3.6/dumpelf.c:262 #1 0x41655d in dump_phdr ../pax-utils-1.3.6/dumpelf.c:336 #2 0x405789 in dumpelf ../pax-utils-1.3.6/dumpelf.c:83 #3 0x405789 in dumpelf_file ../pax-utils-1.3.6/dumpelf.c:153 #4 0x405789 in parseargs ../pax-utils-1.3.6/dumpelf.c:576 #5 0x405789 in main ../pax-utils-1.3.6/dumpelf.c:604 #6 0x7ff499d7d1f6 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #7 0x7ff499d7d2ab in __libc_start_main_impl ../csu/libc-start.c:381 #8 0x40a290 (/usr/bin/dumpelf+0x40a290)
Mike, I don't know how much you monitor the toolchain@ alias. Since you are one of the main author, you may be interested in this.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pax-utils.git/commit/?id=c1759f9bf28edb910208a7c7fbb4b373fe8b1297 commit c1759f9bf28edb910208a7c7fbb4b373fe8b1297 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2024-01-25 05:19:50 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2024-01-25 05:19:50 +0000 scanelf: fix hashtable overflow checks Make sure we use the right offset, and make sure the numbers to check don't overflow themselves -- if nbuckets & nchains are 32-bit, and if we multiply them by 4, we can easily overflow before we get a chance to see if they will fit within the memory range. Bug: https://bugs.gentoo.org/890028 Signed-off-by: Mike Frysinger <vapier@gentoo.org> scanelf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
(In reply to Agostino Sarubbo from comment #0) > Created attachment 847774 [details] > scanelf testcase > > scanelf -s '*' 1.crashes.elf should be fixed now (In reply to Agostino Sarubbo from comment #1) > There is also a crash in dumpelf: > > dumpelf 1.crashes.elf i can't reproduce this > ==6304==ERROR: AddressSanitizer: unknown-crash on address 0x7ff4963c7000 at > pc 0x000000415aaa bp 0x7ffd1fb5c0e0 sp 0x7ffd1fb5c0d8 > READ of size 4 at 0x7ff4963c7000 thread T0 > #0 0x415aa9 in dump_notes ../pax-utils-1.3.6/dumpelf.c:262 glancing at this line/section, it seems like we already verify the memory is valid before we read it, so not sure what this is tripping on.
(In reply to SpanKY from comment #4) > i can't reproduce this > > > ==6304==ERROR: AddressSanitizer: unknown-crash on address 0x7ff4963c7000 at > > pc 0x000000415aaa bp 0x7ffd1fb5c0e0 sp 0x7ffd1fb5c0d8 > > READ of size 4 at 0x7ff4963c7000 thread T0 > > #0 0x415aa9 in dump_notes ../pax-utils-1.3.6/dumpelf.c:262 > > glancing at this line/section, it seems like we already verify the memory is > valid before we read it, so not sure what this is tripping on. I still can reproduce on -9999 (a1d0123581ede02b54cf2c071507612dde25236c)
let's keep this bug focused on scanelf_file_get_symtabs. that was distinct, and it's fixed. the dumpelf stuff is a completely diff codebase, and not really important as it's only a low level curiosity type of thing. i keep debating whether to include it in the default install. i can repro one ASAN crash in dumpelf (out of bounds read), but i'm not sure it's a real bug, or it's a 1-byte boundary that ASAN doesn't like. still poking it.