[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28666

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
           Assignee|unassigned at sourceware dot org   |mark at klomp dot org
                 CC|                            |mark at klomp dot org
   Last reconfirmed|                            |2021-12-07

--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
It does indeed replicate under valgrind using eu-stack with any build:

$ valgrind eu-stack --core poc1 
==444== Memcheck, a memory error detector
==444== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==444== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==444== Command: eu-stack --core poc1
==444== 
==444== Invalid read of size 8
==444==    at 0x4C2E68C: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1034)
==444==    by 0x4E3C2FB: UnknownInlinedFun (string3.h:57)
==444==    by 0x4E3C2FB: elf32_xlatetom (elf32_xlatetom.c:100)
==444==    by 0x5086081: dwfl_link_map_report (link_map.c:894)
==444==    by 0x5087D7A: dwfl_core_file_report@@ELFUTILS_0.158
(core-file.c:532)
==444==    by 0x402736: parse_opt (stack.c:590)
==444==    by 0x58B7E83: group_parse (argp-parse.c:256)
==444==    by 0x58B7E83: parser_finalize (argp-parse.c:603)
==444==    by 0x58B7E83: argp_parse (argp-parse.c:921)
==444==    by 0x401CE5: main (stack.c:690)
==444==  Address 0x4025000 is not stack'd, malloc'd or (recently) free'd

I see what is going on. In link_map we try to read in the phdrs, but we can
only read a small amount (the ph_num field is crazy big). So we set the
in.d_size to just the size we can read in. But then for the conversion we set
out.d_size based on the crazy big ph_num. Then we try to convert not just the
phdrs that we could read, but a much bigger amount. And crash...

This is an odd failure, it only happens when trying to read a big endian core
file on an little endian architecture (or the other way around), and that core
file is also clearly corrupted.

-- 
You are receiving this mail because:
You are on the CC list for the bug.