[Bug general/24385] Regression lead to Invalid Address Deference, in handle_elf function in /src/strip.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24385 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mark at klomp dot org Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- This code is only triggered when stripping into a new file with -o. With that it can be replicated under valgrind: ==1008== Command: src/strip -o POC1.stripped ./POC1 ==1008== ==1008== Invalid read of size 4 ==1008==at 0x804EB0A: handle_elf.constprop.2 (strip.c:1978) ==1008==by 0x804F2F7: process_file (strip.c:769) ==1008==by 0x8049AFF: main (strip.c:272) ==1008== Address 0xfec3c840 is not stack'd, malloc'd or (recently) free'd ==1008== ==1008== ==1008== Process terminating with default action of signal 11 (SIGSEGV) ==1008== Access not within mapped region at address 0xFEC3C840 The file is obviously illformed because the symbol refers to a non-existing section. The fix is simple: diff --git a/src/strip.c b/src/strip.c index a73009d..4cd8750 100644 --- a/src/strip.c +++ b/src/strip.c @@ -1975,6 +1975,7 @@ handle_elf (int fd, Elf *elf, const char *prefix, const ch && shndxdata->d_buf != NULL); size_t sidx = (sym->st_shndx != SHN_XINDEX ? sym->st_shndx : xshndx); + elf_assert (sidx < shnum); sec = shdr_info[sidx].idx; if (sec != 0) commit f03ac75239e0981deaf4aa18f66f423bcc5ce051 Author: Mark Wielaard Date: Wed Mar 27 21:54:06 2019 +0100 strip: Files with symbols referring to non-existing sections are illformed The check added in commit 4540ea98c "strip: Fix check test for SHN_XINDEX symbol" was not complete. The (extended) section index should also exist. If it doesn't exist, mark the file as illformed. https://sourceware.org/bugzilla/show_bug.cgi?id=24385 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24385] Check symbols only refer to existing sections in eu-strip handle_elf
https://sourceware.org/bugzilla/show_bug.cgi?id=24385 Mark Wielaard changed: What|Removed |Added Summary|Regression lead to Invalid |Check symbols only refer to |Address Deference, in |existing sections in |handle_elf function in |eu-strip handle_elf |/src/strip.c| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/24387] dwfl_segment_report_module doesn't check whether the phdrs data read from core file is truncated
https://sourceware.org/bugzilla/show_bug.cgi?id=24387 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mark at klomp dot org Resolution|--- |FIXED Summary|Invalid address Deference |dwfl_segment_report_module |in elf32_xlatetom function |doesn't check whether the |in libelf/elf32_xlatetom.c |phdrs data read from core ||file is truncated --- Comment #2 from Mark Wielaard --- Can be replicated with valgrind. It is indeed similar to bug #24103. Both of which aren't bugs in elf(64|32)_xlatetom, but dwfl_segment_report_module should also check that the core file isn't truncated so that not all of the phdrs can be read. Fix is similar: diff --git a/libdwfl/dwfl_segment_report_module.c b/libdwfl/dwfl_segment_report_ index f6ad39b..76ba150 100644 --- a/libdwfl/dwfl_segment_report_module.c +++ b/libdwfl/dwfl_segment_report_module.c @@ -412,6 +412,12 @@ dwfl_segment_report_module (Dwfl *dwfl, int ndx, const char start + phoff, xlatefrom.d_size)) return finish (); + /* ph_buffer_size will be zero if we got everything from the initial + buffer, otherwise it will be the size of the new buffer that + could be read. */ + if (ph_buffer_size != 0) +xlatefrom.d_size = ph_buffer_size; + xlatefrom.d_buf = ph_buffer; bool class32 = ei_class == ELFCLASS32; commit e1f353b785b5cdb20d8004b6c4070c3e2a783e8b Author: Mark Wielaard Date: Wed Mar 27 22:32:21 2019 +0100 libdwfl: Sanity check partial core file phdrs data read. When reading the phdrs data from the core file check if we got everything, or just part of the data. https://sourceware.org/bugzilla/show_bug.cgi?id=24387 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
