[Bug general/23786] Divide-by-zero Problem in function arlib_add_symbols() in arlib.c in elfutils-0.174
https://sourceware.org/bugzilla/show_bug.cgi?id=23786 --- Comment #2 from wcventure --- Created attachment 11337 --> https://sourceware.org/bugzilla/attachment.cgi?id=11337&action=edit POC2 Please use " ./eu-ranlib $POC " to reproduce this bug. This bug was discovered by NTU Cyber-Security-Lab, for fuzzing research work. If you have any questions, please let me know. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/23786] New: Divide-by-zero Problem in function arlib_add_symbols() in arlib.c in elfutils-0.174
https://sourceware.org/bugzilla/show_bug.cgi?id=23786 Bug ID: 23786 Summary: Divide-by-zero Problem in function arlib_add_symbols() in arlib.c in elfutils-0.174 Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: critical Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: wcventure at 126 dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Hi, I found some floating point exception in function arlib_add_symbols() in arlib.c of the latest elfutils-0.174 code base. I have confirmed them with GDB and Address Sanitizer. Here are the POC files. Please use " ./eu-ranlib $POC " to reproduce this bug. I'll also show you the debugging process. It seems that this is caused by the divide-by-zero. In arlib.c:255, there exist a division calculation: > int nsyms = shdr->sh_size / shdr->sh_entsize; I can provide you some testcases to make shdr->sh_entsize = 0. And you can use the testcases to reproduce the bug. Divide by zero is bad. We need to make a check before doing division calculation. --- Comment #1 from wcventure --- Created attachment 11336 --> https://sourceware.org/bugzilla/attachment.cgi?id=11336&action=edit POC1 I have also confirmed them with Address Sanitizer. The ASAN dumps the stack trace as follows: ASAN:DEADLYSIGNAL = ==2496==ERROR: AddressSanitizer: FPE on unknown address 0x004065d8 (pc 0x004065d8 bp 0x7ffd4c109620 sp 0x7ffd4c109550 T0) #0 0x4065d7 in arlib_add_symbols /media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/src/arlib.c:255 #1 0x4029c5 in handle_file /media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/src/ranlib.c:193 #2 0x4029c5 in main /media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/src/ranlib.c:110 #3 0x7fc97b51982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #4 0x403d28 in _start (/media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/build/bin/eu-ranlib+0x403d28) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: FPE /media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/src/arlib.c:255 in arlib_add_symbols ==2496==ABORTING Aborted -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23787] New: Invalid Address Deference problem in function elf_end in libelf the latest elfutils-0.174
https://sourceware.org/bugzilla/show_bug.cgi?id=23787 Bug ID: 23787 Summary: Invalid Address Deference problem in function elf_end in libelf the latest elfutils-0.174 Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libelf Assignee: unassigned at sourceware dot org Reporter: wcventure at 126 dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 11338 --> https://sourceware.org/bugzilla/attachment.cgi?id=11338&action=edit POC1 Hi, Our fuzzer found an Invalid Address Deference problem in function elf_end in libelf the latest elfutils-0.174 code base. I have confirmed them with Address Sanitizer, too. The function elf_end is called by size.c. Here are the POC files. Please use " ./eu-size $POC " to reproduce this bug. The ASAN dumps the stack trace as follows: ASAN:DEADLYSIGNAL = ==21938==ERROR: AddressSanitizer: SEGV on unknown address 0x0010 (pc 0x7f1a0efb3cd6 bp 0x7ffd04b5dc40 sp 0x7ffd04b5db50 T0) ==21938==The signal is caused by a READ memory access. ==21938==Hint: address points to the zero page. #0 0x7f1a0efb3cd5 in elf_end (/usr/lib/x86_64-linux-gnu/libelf.so.1+0x4cd5) #1 0x405aa2 in handle_ar /media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/src/size.c:373 #2 0x401c7a in process_file /media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/src/size.c:294 #3 0x401c7a in main /media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/src/size.c:186 #4 0x7f1a0ec0582f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #5 0x4029f8 in _start (/media/hjwang/01D3344861A8D2E0/wcventure/Project/elfutils/build/bin/eu-size+0x4029f8) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/usr/lib/x86_64-linux-gnu/libelf.so.1+0x4cd5) in elf_end ==21938==ABORTING Aborted -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23787] Invalid Address Deference problem in function elf_end in libelf the latest elfutils-0.174
https://sourceware.org/bugzilla/show_bug.cgi?id=23787 --- Comment #1 from wcventure --- Created attachment 11339 --> https://sourceware.org/bugzilla/attachment.cgi?id=11339&action=edit POC2 Please use " ./eu-size $POC " to reproduce this bug. This bug was discovered by NTU Cyber-Security-Lab, for fuzzing research work. If you have any questions, please let me know. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] strip, unstrip: Handle SHT_GROUP correctly.
On Sat, 2018-10-13 at 10:46 +0200, Mark Wielaard wrote:
> The usage of annobin in Fedora showed a couple of bugs when using
> eu-strip and eu-unstrip on ET_REL files that contain multiple group
> sections.
>
> When stripping we should not remove the SHF_GROUP flag from sections
> even if the group section itself might be removed. Either the section
> itself gets removed, and so the flag doesn't matter. Or it gets moved
> together with the group section into the debug file, and then it
> still
> needs to have the flag set. Also we would "renumber" the section
> group
> flag field (which isn't a section index, and so shouldn't be
> changed).
>
> Often the group sections have the exact same name (".group"), flags
> (none) and sometimes the same sizes. Which makes matching them hard.
> Extract the group signature and compare those when comparing two
> group sections.
Pushed to master.
Re: Handling pgoff in perf elf mmap/mmap2 elf info
On Montag, 15. Oktober 2018 23:06:07 CEST Milian Wolff wrote: > On Montag, 15. Oktober 2018 23:04:52 CEST Mark Wielaard wrote: > > Hi Milian, > > > > On Mon, 2018-10-15 at 22:38 +0200, Milian Wolff wrote: > > > here's one example of mmap events recorded by perf: > > > > > > 0x7fac5ec0b000 to 0x7fac5ed9a000, len = 0x18f000, offset > > > =0r--p/usr/lib/libstdc++.so.6.0.25 > > > 0x7fac5ec94000 to 0x7fac5ed8a000, len =0xf6000, offset > > > = 0x89000---p/usr/lib/libstdc++.so.6.0.25 > > > 0x7fac5ec94000 to 0x7fac5ed4c000, len =0xb8000, offset > > > = 0x89000r-xp/usr/lib/libstdc++.so.6.0.25 > > > 0x7fac5ed4c000 to 0x7fac5ed89000, len =0x3d000, offset > > > = 0x141000r--p/usr/lib/libstdc++.so.6.0.25 > > > 0x7fac5ed8a000 to 0x7fac5ed97000, len = 0xd000, offset > > > = 0x17e000rw-p/usr/lib/libstdc++.so.6.0.25 > > > > Could you also post the matching phdr output for the file? > > eu-readelf -l /usr/lib/libstdc++.so.6.0.25 should show it. > > That way we can see how the PT_LOAD segments map to the mmap events. > > Sure: > > $ eu-readelf -l /usr/lib/libstdc++.so.6.0.25 > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz > MemSiz Flg Align > LOAD 0x00 0x 0x 0x088fa8 > 0x088fa8 R 0x1000 > LOAD 0x089000 0x00089000 0x00089000 0x0b7ae1 > 0x0b7ae1 R E 0x1000 > LOAD 0x141000 0x00141000 0x00141000 0x03cfe0 > 0x03cfe0 R 0x1000 > LOAD 0x17e8e0 0x0017f8e0 0x0017f8e0 0x00b8b8 > 0x00ed60 RW 0x1000 > DYNAMIC0x1873a8 0x001883a8 0x001883a8 0x0001e0 > 0x0001e0 RW 0x8 > NOTE 0x0002a8 0x02a8 0x02a8 0x24 > 0x24 R 0x4 > NOTE 0x17dfc0 0x0017dfc0 0x0017dfc0 0x20 > 0x20 R 0x8 > TLS0x17e8e0 0x0017f8e0 0x0017f8e0 0x00 > 0x20 R 0x8 > GNU_EH_FRAME 0x149558 0x00149558 0x00149558 0x007f04 > 0x007f04 R 0x4 > GNU_STACK 0x00 0x 0x 0x00 > 0x00 RW 0x10 > GNU_RELRO 0x17e8e0 0x0017f8e0 0x0017f8e0 0x00b720 > 0x00b720 R 0x1 > > Section to Segment mapping: > Segment Sections... >00 [RO: .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version > .gnu.version_d .gnu.version_r .rela.dyn] >01 [RO: .init .text .fini] >02 [RO: .rodata .eh_frame_hdr .eh_frame .gcc_except_table > .note.gnu.property] >03 [RELRO: .tbss .init_array .fini_array .data.rel.ro .dynamic .got] > .got.plt .data .bss >04 [RELRO: .dynamic] >05 [RO: .note.gnu.build-id] >06 [RO: .note.gnu.property] >07 [RELRO: .tbss] >08 [RO: .eh_frame_hdr] >09 >10 [RELRO: .tbss .init_array .fini_array .data.rel.ro .dynamic .got] So, Mark - any chance you could have a look at the above and give us your feedback? When I compare the actual mmap events with the LOAD segments, there are some similarities, but also some discrepancies. Note how the mmap sizes always differ from the FileSiz header value. And the offsets also sometimes mismatch, e.g. for the last segment / mmap event we get 0x17f8e0 in the header, but 0x17e000 in the mmap event...: LOAD 0x17e8e0 0x0017f8e0 0x0017f8e0 0x00b8b8 0x00ed60 RW 0x1000 0x7fac5ed8a000 to 0x7fac5ed97000, len = 0xd000, offset = 0x17e000 rw-p/usr/lib/libstdc++.so.6.0.25 I'm pretty confused here! -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173
https://sourceware.org/bugzilla/show_bug.cgi?id=23673 --- Comment #20 from Mark Wielaard --- (In reply to Michael Hudson-Doyle from comment #19) > I see a similar looking failure on arm64 on Ubuntu 18.10: > > https://launchpadlibrarian.net/391377304/buildlog_ubuntu-cosmic-arm64. > elfutils_0.170-0.5_BUILDING.txt.gz So, if possible could you build with current git or 0.174 + the patch from comment #14 or commit 69d6e67eee30c483ba53a8e1da1b3568033e3ddecommit 69d6e67eee30c483ba53a8e1da1b3568033e3dde > I've gdb-ed this to the point that the key difference between a working > system (Ubuntu 18.04) and the failing one is that libc.so.6 has a lot more > entries in .eh_frame_hdr in the failing system. On 18.04 it fails to find a > fde for abort() (or raise, I think) and unwinds using .debug_frame and that > succeeds. On 18.10 it finds a fde for both raise and abort but fails to > successfully unwind past abort using it. I don't know either why the newer > libc.so.6 has a bigger eh_frame_hdr (it is glibc 2.28 vs 2.27 but also built > with newer gcc and binutils) or why unwinding using eh_frame info fails. In principle the .eh_frame and .debug_frame should provide the same CFI, although encoded slightly differently. Maybe there is a difference? You should be able to find both with eu-readelf --debug-dump=frame -- You are receiving this mail because: You are on the CC list for the bug.
Re: Handling pgoff in perf elf mmap/mmap2 elf info
Hi Milian, On Wed, Oct 17, 2018 at 04:52:42PM +0200, Milian Wolff wrote: > On Montag, 15. Oktober 2018 23:06:07 CEST Milian Wolff wrote: > > On Montag, 15. Oktober 2018 23:04:52 CEST Mark Wielaard wrote: > > > On Mon, 2018-10-15 at 22:38 +0200, Milian Wolff wrote: > > > > here's one example of mmap events recorded by perf: > > > > > > > > 0x7fac5ec0b000 to 0x7fac5ed9a000, len = 0x18f000, offset > > > > =0r--p/usr/lib/libstdc++.so.6.0.25 > > > > 0x7fac5ec94000 to 0x7fac5ed8a000, len =0xf6000, offset > > > > = 0x89000---p/usr/lib/libstdc++.so.6.0.25 > > > > 0x7fac5ec94000 to 0x7fac5ed4c000, len =0xb8000, offset > > > > = 0x89000r-xp/usr/lib/libstdc++.so.6.0.25 > > > > 0x7fac5ed4c000 to 0x7fac5ed89000, len =0x3d000, offset > > > > = 0x141000r--p/usr/lib/libstdc++.so.6.0.25 > > > > 0x7fac5ed8a000 to 0x7fac5ed97000, len = 0xd000, offset > > > > = 0x17e000rw-p/usr/lib/libstdc++.so.6.0.25 > > > > > > Could you also post the matching phdr output for the file? > > > eu-readelf -l /usr/lib/libstdc++.so.6.0.25 should show it. > > > That way we can see how the PT_LOAD segments map to the mmap events. > > > > Sure: > > > > $ eu-readelf -l /usr/lib/libstdc++.so.6.0.25 > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz > > MemSiz Flg Align > > LOAD 0x00 0x 0x 0x088fa8 > > 0x088fa8 R 0x1000 > > LOAD 0x089000 0x00089000 0x00089000 0x0b7ae1 > > 0x0b7ae1 R E 0x1000 > > LOAD 0x141000 0x00141000 0x00141000 0x03cfe0 > > 0x03cfe0 R 0x1000 > > LOAD 0x17e8e0 0x0017f8e0 0x0017f8e0 0x00b8b8 > > 0x00ed60 RW 0x1000 > > DYNAMIC0x1873a8 0x001883a8 0x001883a8 0x0001e0 > > 0x0001e0 RW 0x8 > > NOTE 0x0002a8 0x02a8 0x02a8 0x24 > > 0x24 R 0x4 > > NOTE 0x17dfc0 0x0017dfc0 0x0017dfc0 0x20 > > 0x20 R 0x8 > > TLS0x17e8e0 0x0017f8e0 0x0017f8e0 0x00 > > 0x20 R 0x8 > > GNU_EH_FRAME 0x149558 0x00149558 0x00149558 0x007f04 > > 0x007f04 R 0x4 > > GNU_STACK 0x00 0x 0x 0x00 > > 0x00 RW 0x10 > > GNU_RELRO 0x17e8e0 0x0017f8e0 0x0017f8e0 0x00b720 > > 0x00b720 R 0x1 > > > > Section to Segment mapping: > > Segment Sections... > >00 [RO: .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version > > .gnu.version_d .gnu.version_r .rela.dyn] > >01 [RO: .init .text .fini] > >02 [RO: .rodata .eh_frame_hdr .eh_frame .gcc_except_table > > .note.gnu.property] > >03 [RELRO: .tbss .init_array .fini_array .data.rel.ro .dynamic .got] > > .got.plt .data .bss > >04 [RELRO: .dynamic] > >05 [RO: .note.gnu.build-id] > >06 [RO: .note.gnu.property] > >07 [RELRO: .tbss] > >08 [RO: .eh_frame_hdr] > >09 > >10 [RELRO: .tbss .init_array .fini_array .data.rel.ro .dynamic .got] > > So, Mark - any chance you could have a look at the above and give us your > feedback? Sorry, I haven't yet looked at this deeply. But some quick comments. The mmap events do seem to correspond to the PT_LOAD segments. At least the offsets are. Why the second on is mmapped twice I don't know. The difference in length for the last 3 seems to be that the mmaps are aligned up (0x1000, 4K, page size) > When I compare the actual mmap events with the LOAD segments, there are some > similarities, but also some discrepancies. Note how the mmap sizes always > differ from the FileSiz header value. And the offsets also sometimes > mismatch, > e.g. for the last segment / mmap event we get 0x17f8e0 in the header, but > 0x17e000 in the mmap event...: > > LOAD 0x17e8e0 0x0017f8e0 0x0017f8e0 0x00b8b8 > 0x00ed60 RW 0x1000 > > 0x7fac5ed8a000 to 0x7fac5ed97000, len = 0xd000, offset = 0x17e000 > > rw-p/usr/lib/libstdc++.so.6.0.25 > > I'm pretty confused here! I think the differences can be explained by the fact that mmap will use aligned offsets and length. In theory libdwfl just needs to see one mmap even and should then be able to use the phdrs PT_LOAD headers to see how the whole file is mmapped into memory. Maybe something goes wrong there. And reporting multiple events for the same file might confuse things. Cheers, Mark
[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173
https://sourceware.org/bugzilla/show_bug.cgi?id=23673 --- Comment #21 from Michael Hudson-Doyle --- (In reply to Mark Wielaard from comment #20) > (In reply to Michael Hudson-Doyle from comment #19) > > I see a similar looking failure on arm64 on Ubuntu 18.10: > > > > https://launchpadlibrarian.net/391377304/buildlog_ubuntu-cosmic-arm64. > > elfutils_0.170-0.5_BUILDING.txt.gz > > So, if possible could you build with current git or 0.174 + the patch from > comment #14 or commit 69d6e67eee30c483ba53a8e1da1b3568033e3ddecommit > 69d6e67eee30c483ba53a8e1da1b3568033e3dde Oh hmm current git passes! Sorry for the noise. Oh and obviously f881459ffc95b6fad51aa055a158ee14814073aa fixes this (somehow I failed to read the git log correctly and had to bisect to find it but there's no real excuse for that). > > I've gdb-ed this to the point that the key difference between a working > > system (Ubuntu 18.04) and the failing one is that libc.so.6 has a lot more > > entries in .eh_frame_hdr in the failing system. On 18.04 it fails to find a > > fde for abort() (or raise, I think) and unwinds using .debug_frame and that > > succeeds. On 18.10 it finds a fde for both raise and abort but fails to > > successfully unwind past abort using it. I don't know either why the newer > > libc.so.6 has a bigger eh_frame_hdr (it is glibc 2.28 vs 2.27 but also built > > with newer gcc and binutils) or why unwinding using eh_frame info fails. > > In principle the .eh_frame and .debug_frame should provide the same CFI, > although encoded slightly differently. Maybe there is a difference? You > should be able to find both with eu-readelf --debug-dump=frame I wrote most of what follows while waiting for the test run above to complete but for the record... So something I forgot to mention is that the newer glibc has no .debug_frame (not even in the /usr/lib/debug file that has the other debug data). So in a sense the fact that elfutils is trying to unwind using eh_frame and not trying the debug_frame data at all is actually not relevant here. That said, here is the debug_frame CFI from libc in the working environment: [ 3d28] FDE length=36 cie=[ 3d18] CIE_pointer: 15640 initial_location: +0x00033760 address_range:0x228 Program: advance_loc 1 to 0x4 def_cfa_offset 320 offset r29 (x29) at cfa-320 offset r30 (x30) at cfa-312 advance_loc 2 to 0xc def_cfa_register r29 (x29) advance_loc 1 to 0x10 offset r19 (x19) at cfa-304 offset r20 (x20) at cfa-296 And here is the eh_frame CFI from the libc that fails: [ 2b08] FDE length=28 cie=[ 0] CIE_pointer: 11020 initial_location: +0x000207d8 (offset: 0x207d8) address_range:0x214 (end offset: 0x209ec) Program: advance_loc 1 to 0x207dc def_cfa_offset 320 offset r29 (x29) at cfa-320 offset r30 (x30) at cfa-312 advance_loc 4 to 0x207ec offset r19 (x19) at cfa-304 offset r20 (x20) at cfa-296 nop nop I guess it's the lack of the def_cfa_register r29 in the eh_frame data that is making the difference. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173
https://sourceware.org/bugzilla/show_bug.cgi?id=23673 --- Comment #22 from Mark Wielaard --- (In reply to Michael Hudson-Doyle from comment #21) > (In reply to Mark Wielaard from comment #20) > > (In reply to Michael Hudson-Doyle from comment #19) > > > I see a similar looking failure on arm64 on Ubuntu 18.10: > > > > > > https://launchpadlibrarian.net/391377304/buildlog_ubuntu-cosmic-arm64. > > > elfutils_0.170-0.5_BUILDING.txt.gz > > > > So, if possible could you build with current git or 0.174 + the patch from > > comment #14 or commit 69d6e67eee30c483ba53a8e1da1b3568033e3ddecommit > > 69d6e67eee30c483ba53a8e1da1b3568033e3dde > > Oh hmm current git passes! Sorry for the noise. > > Oh and obviously f881459ffc95b6fad51aa055a158ee14814073aa fixes this Cool. So this is different from the s390x issue. Which we sadly don't yet understand. But if that happens again on s390x an inspection of the CFI and whether it comes from .eh_frame or .debug_frame might be helpful. -- You are receiving this mail because: You are on the CC list for the bug.
