[Bug libelf/24089] New: A Heap-buffer-overflow problem was discovered in the function elf32_xlatetom in elf32_xlatetom.c in libelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24089 Bug ID: 24089 Summary: A Heap-buffer-overflow problem was discovered in the function elf32_xlatetom in elf32_xlatetom.c in libelf 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 11534 --> https://sourceware.org/bugzilla/attachment.cgi?id=11534&action=edit POC1 Hi, A Heap-buffer-overflow problem was discovered in the function elf32_xlatetom in elf32_xlatetom.c in libelf, as distributed in ELFutils 0.147. A crafted ELF input can cause segment faults and I have confirmed them with address sanitizer too. Here are the POC files. Please use "./eu-readelf -a $POC" to reproduce the error. $ git log > commit 1dabad36ee28aa76b8cf14b6426b379cabee6def > Author: Jim Wilson > Date: Thu Dec 27 15:25:49 2018 -0800 > > RISC-V: Improve riscv64 core file support. > > This fixes two problems. The offset for x1 is changed from 1 to 8 because > this is a byte offset not a register skip count. Support for reading the > PC value is added. This requires changing the testsuite to match the new > readelf output for coredumps. > > Signed-off-by: Jim Wilson The ASAN dumps the stack trace as follows: > = > ==26819==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x603000b4 at pc 0x7f07b3e4ee2b bp 0x7ffe3ddce530 sp 0x7ffe3ddcdcd8 > READ of size 1 at 0x603000b4 thread T0 > #0 0x7f07b3e4ee2a in memmove > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x7ae2a) > #1 0x7f07b351469c in elf32_xlatetom > /home/wencheng/Experiment/elfutils/libelf/elf32_xlatetom.c:116 > #2 0x410e3c in convert > /home/wencheng/Experiment/elfutils/src/readelf.c:11305 > #3 0x436e64 in handle_core_item > /home/wencheng/Experiment/elfutils/src/readelf.c:11359 > #4 0x4447d4 in handle_core_items > /home/wencheng/Experiment/elfutils/src/readelf.c:11641 > #5 0x4447d4 in handle_core_note > /home/wencheng/Experiment/elfutils/src/readelf.c:12164 > #6 0x4a006c in handle_notes_data > /home/wencheng/Experiment/elfutils/src/readelf.c:12248 > #7 0x4c5b47 in handle_notes > /home/wencheng/Experiment/elfutils/src/readelf.c:12315 > #8 0x4c5b47 in process_elf_file > /home/wencheng/Experiment/elfutils/src/readelf.c:1000 > #9 0x4c5b47 in process_dwflmod > /home/wencheng/Experiment/elfutils/src/readelf.c:760 > #10 0x7f07b3a1fe9c in dwfl_getmodules > /home/wencheng/Experiment/elfutils/libdwfl/dwfl_getmodules.c:86 > #11 0x41399c in process_file > /home/wencheng/Experiment/elfutils/src/readelf.c:868 > #12 0x405df6 in main /home/wencheng/Experiment/elfutils/src/readelf.c:350 > #13 0x7f07b2f3582f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > #14 0x406ef8 in _start > (/home/wencheng/Experiment/elfutils/build/bin/eu-readelf+0x406ef8) > > 0x603000b4 is located 0 bytes to the right of 20-byte region > [0x603000a0,0x603000b4) > allocated by thread T0 here: > #0 0x7f07b3eb2b90 in __interceptor_malloc > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb90) > #1 0x7f07b3597080 in elf_getdata_rawchunk > /home/wencheng/Experiment/elfutils/libelf/elf_getdata_rawchunk.c:88 > > SUMMARY: AddressSanitizer: heap-buffer-overflow > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x7ae2a) in memmove > Shadow bytes around the buggy address: > 0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c067fff8000: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 > =>0x0c067fff8010: 00 fa fa fa 00 00[04]fa fa fa fa fa fa fa fa fa > 0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c067fff8060: 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
[Bug libelf/24089] A Heap-buffer-overflow problem was discovered in the function elf32_xlatetom in elf32_xlatetom.c in libelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24089 --- Comment #1 from wcventure --- Created attachment 11535 --> https://sourceware.org/bugzilla/attachment.cgi?id=11535&action=edit POC2 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] RISC-V: Add untested 32-bit core file support.
On Thu, 2018-12-27 at 15:27 -0800, Jim Wilson wrote:
> This conflicts with the previoues two patches. Adds 32-bit support exactly
> the
> same way that the sparc backend handles 32- and 64-bit core file support. The
> 64-bit core file support was tested and still works same as before.
I don't really like adding code that cannot be tested. But it does look
the 32-bit port isn't far off, just waiting for the next linux/glibc
release to settle the time_t ABI. And the code does look correct.
Except for...
> static const Ebl_Register_Location prstatus_regs[] =
>{
> -{ .offset = 8, .regno = 1, .count = 31, .bits = 64 } /* x1..x31 */
> +{ .offset = BITS/8, .regno = 1, .count = 31, .bits = 64 } /* x1..x31 */
>};
Should that be .bits = BITS ?
Thanks,
Mark
Re: RISC-V support
On Sat, 2019-01-12 at 00:23 +0100, Kurt Roeckx wrote:
> I've been looking at mips, and it seems to have many different
> ABIs too. A patch I've received does this:
> int
> mips_return_value_location (Dwarf_Die *functypedie, const Dwarf_Op
> **locp)
> {
> /* First find the ABI used by the elf object */
> enum mips_abi abi = find_mips_abi(functypedie->cu->dbg->elf);
>
> The patch only supports 6 ABIs, but I think there are really over
> 10 ABIs.
But how many are actually used? Which does Debian support?
> Maybe it would be good that we only need to determine the ABI
> once, instead of each time the function is called.
Yes, so instead of having each hook find the correct abi, you can do
that in the init hook once. And then either assigning a abi specific
callback hook, or setting some struct ebl data field (ppc64 added one
for function descriptor support for example).
Cheers,
Mark
Re: RISC-V support
On Sat, Jan 12, 2019 at 11:35:48PM +0100, Mark Wielaard wrote:
> On Sat, 2019-01-12 at 00:23 +0100, Kurt Roeckx wrote:
> > I've been looking at mips, and it seems to have many different
> > ABIs too. A patch I've received does this:
> > int
> > mips_return_value_location (Dwarf_Die *functypedie, const Dwarf_Op
> > **locp)
> > {
> > /* First find the ABI used by the elf object */
> > enum mips_abi abi = find_mips_abi(functypedie->cu->dbg->elf);
> >
> > The patch only supports 6 ABIs, but I think there are really over
> > 10 ABIs.
>
> But how many are actually used? Which does Debian support?
I'm not at all an export of mips, I really don't know that much
about it.
We have 3 mips ports, but mips and mipsel are the same ABI, it's
just big endian vs little endian. But as far as I understand it,
we transitioned those 2 ports from one ABI to an other, so they
are compatible with yet an other ABI. I think that at least makes
4 ABIs we care about. And I think gcc supports many different ones
depending on compiler flags you give to it, but I really don't know.
Kurt
Re: [PATCH] RISC-V: Add untested 32-bit core file support.
On Sat, Jan 12, 2019 at 2:29 PM Mark Wielaard wrote:
> I don't really like adding code that cannot be tested. But it does look
> the 32-bit port isn't far off, just waiting for the next linux/glibc
> release to settle the time_t ABI. And the code does look correct.
> Except for...
We don't expect 32-bit desktop linux distros, but there are folks that
want 32-bit embedded linux. A few companies have gotten it working,
but only Andes is trying to upstream patches so far, and as you
mentioned that is waiting for the time_t ABI. Meanwhile, it should be
possible to build a busy-box style 32-bit linux system, using an old
obsolete pre-upstream glibc port, but that isn't useful for real
development work.
> > static const Ebl_Register_Location prstatus_regs[] =
> >{
> > -{ .offset = 8, .regno = 1, .count = 31, .bits = 64 } /* x1..x31 */
> > +{ .offset = BITS/8, .regno = 1, .count = 31, .bits = 64 } /* x1..x31 */
> >};
>
> Should that be .bits = BITS ?
Yes, sorry, I was looking at the offset field and completely missed
the bits member at the end. Do you want me to submit an updated
patch?
Jim
Re: RISC-V support
On Sat, Jan 12, 2019 at 3:21 PM Kurt Roeckx wrote: > > But how many are actually used? Which does Debian support? > > I'm not at all an export of mips, I really don't know that much > about it. It depends on how you count ABIs, but yes there have unfortunately been a lot of them over the years. As a practical matter, you should only need support for the (old) 32 bit ABI with pic support, the n32 ABI (which is 32-bit types on a 64-bit machine like the x86_64 x32 ABI), and the (new) 64-bit ABI. Those are the only ones that gcc supports for linux and other POSIX operating systems. These exist in both big-endian and little-endian forms. There are a bunch of other ABIs or ABI variants that were only ever supported for embedded systems, or were used on old pre-shared library systems, or were never implemented in FSF GCC. So you can ignore all of those. Jim
Re: RISC-V support
On Sat, Jan 12, 2019 at 05:06:18PM -0800, Jim Wilson wrote: > On Sat, Jan 12, 2019 at 3:21 PM Kurt Roeckx wrote: > > > But how many are actually used? Which does Debian support? > > > > I'm not at all an export of mips, I really don't know that much > > about it. > > It depends on how you count ABIs, but yes there have unfortunately > been a lot of them over the years. > > As a practical matter, you should only need support for the (old) 32 > bit ABI with pic support, the n32 ABI (which is 32-bit types on a > 64-bit machine like the x86_64 x32 ABI), and the (new) 64-bit ABI. > Those are the only ones that gcc supports for linux and other POSIX > operating systems. These exist in both big-endian and little-endian > forms. O32 really has at least the following variants: - O32 FP32 - O32 FPXX - O32 FP64 - O32 FP64A They are all different ABIs related to the floating points. It's my understanding that Debian's mips and mipsel port was O32 FP32 and is now using O32 FPXX, and that mips64el is using N64. Kurt
