[Bug tools/32672] eu-strip SEGV (illegal read access) in validate_str (libelf/elf_strptr.c:60)
https://sourceware.org/bugzilla/show_bug.cgi?id=32672 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Wielaard --- commit b16f441cca0a4841050e3215a9f120a6d8aea918 Author: Mark Wielaard Date: Thu Feb 13 00:02:32 2025 +0100 libelf: Handle elf_strptr on section without any data In the unlikely situation that elf_strptr was called on a section with sh_size already set, but that doesn't have any data yet we could crash trying to verify the string to return. This could happen for example when a new section was created with elf_newscn, but no data having been added yet. * libelf/elf_strptr.c (elf_strptr): Check strscn->rawdata_base is not NULL. https://sourceware.org/bugzilla/show_bug.cgi?id=32672 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32318] client should avoid url duplication for different ima:FOO modes
https://sourceware.org/bugzilla/show_bug.cgi?id=32318 Frank Ch. Eigler changed: What|Removed |Added Assignee|unassigned at sourceware dot org |fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- Created attachment 15951 --> https://sourceware.org/bugzilla/attachment.cgi?id=15951&action=edit possible implementation -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32318] client should avoid url duplication for different ima:FOO modes
https://sourceware.org/bugzilla/show_bug.cgi?id=32318 --- Comment #2 from Frank Ch. Eigler --- While thinking through implications of this change and the preexisting configuration possibilities, I happened across this unfortunate finding, added to doc/debuginfod-client-config.7 It is possible for IMA configurations to be ambiguous, for example if a requested object is queried through a \fBDEBUGINFOD_URLS\fP specification that includes \fImultiple\fP servers with \fIdifferent\fP \fIima:\fP policy modes. Consider if the object is available from each of those servers, but with an absent or invalid signature. The client may query all servers concurrently. If the client happens to receive the object from an \fIima:enforcing\fP policy server first, the query will rejected, but if it's from an \fIima:ignore\fP policy server, the query will succeed. Let's assume this isn't easily avoidable. If so, then the possible implementation patch attachment is pointless, because its results in the subject case will be flatly in the ambiguous category. (The code above happens to squash it into ima:ignore, but that's an implementation artifact accident.) It is definitely NOT equivalent to the "ima:permissive" mode we have repeatedly discussed and noted in bug #31842. (The multiple-modes ambiguity would remain EVEN IF we had a first class ima:permissive mode.) (Why is this not easily avoidable? One reason relates to the way we use libcurl. We deliberately launch multiple outgoing queries to named servers concurrently. As soon as any one starts feeding us data, we abort the queries to all the others, to avoid downloading something potentially large multiple times. It's non-deterministic.) -- You are receiving this mail because: You are on the CC list for the bug.
☠ Buildbot (Sourceware): elfutils - failed test (failure) (main)
A new failure has been detected on builder elfutils-debian-ppc64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#/builders/63/builds/450 Build state: failed test (failure) Revision: b38e562a4c907e08171c76b8b2def8464d5a104a Worker: debian-ppc64 Build Reason: (unknown) Blamelist: Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/6/logs/stdio - warnings (4): https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/6/logs/warnings__4_ - 7: make check ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/11/logs/stdio - 12: pass .bunsen.source.* ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/12/logs/stdio - 13: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/13/logs/stdio - 14: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/14/logs/stdio - 15: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/450/steps/15/logs/stdio
☺ Buildbot (Sourceware): elfutils - build successful (main)
A restored build has been detected on builder elfutils-debian-ppc64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#/builders/63/builds/451 Build state: build successful Revision: 73db9d2021cab9e23fd734b0a76a612d52a6f1db Worker: debian-ppc64 Build Reason: (unknown) Blamelist: Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/6/logs/stdio - warnings (4): https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/6/logs/warnings__4_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/11/logs/stdio - 12: pass .bunsen.source.* ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/12/logs/stdio - 13: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/13/logs/stdio - 14: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/14/logs/stdio - 15: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/451/steps/15/logs/stdio
Re: [PATCH] libelf, readelf: Use validate_str also to check dynamic symstr data
Hi Aaron, On Thu, Feb 13, 2025 at 03:35:03PM -0500, Aaron Merey wrote: > On Mon, Feb 10, 2025 at 1:27 PM Mark Wielaard wrote: > > When dynsym/str was read through eu-readelf --dynamic by readelf > > process_symtab the string data was not validated, possibly printing > > unallocated memory past the end of the symstr data. Fix this by > > truning the elf_strptr validate_str function into a generic > > lib/system.h helper function and use it in readelf to validate the > > strings before use. > > > > * libelf/elf_strptr.c (validate_str): Remove to... > > * lib/system.h (validate_str): ... here. Make inline, simplify > > check and document. > > * src/readelf.c (process_symtab): Use validate_str on symstr_data. > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=32654 > > > > Signed-off-by: Mark Wielaard > > In the commit message "truning" should be "turning". Besides that LGTM. Thanks fixed and pushed. Cheers, Mark
[Bug tools/32656] eu-readelf SEGV (buffer over read) in dump_data_section (src/readelf.c:13312)
https://sourceware.org/bugzilla/show_bug.cgi?id=32656 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Wielaard --- commit 73db9d2021cab9e23fd734b0a76a612d52a6f1db Author: Mark Wielaard Date: Sun Feb 9 00:07:39 2025 +0100 readelf: Skip trying to uncompress sections without a name When combining eu-readelf -z with -x or -p to dump the data or strings in an (corrupted ELF) unnamed numbered section eu-readelf could crash trying to check whether the section name starts with .zdebug. Fix this by skipping sections without a name. * src/readelf.c (dump_data_section): Don't try to gnu decompress a section without a name. (print_string_section): Likewise. https://sourceware.org/bugzilla/show_bug.cgi?id=32656 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/32673] eu-strip SEGV (illegal read access) in gelf_getsymshndx (libelf/gelf_getsymshndx.c:123)
https://sourceware.org/bugzilla/show_bug.cgi?id=32673 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Mark Wielaard --- commit fbf1df9ca286de3323ae541973b08449f8d03aba Author: Mark Wielaard Date: Thu Feb 13 14:59:34 2025 +0100 strip: Verify symbol table is a real symbol table We didn't check the symbol table referenced from the relocation table was a real symbol table. This could cause a crash if that section happened to be an SHT_NOBITS section without any data. Fix this by adding an explicit check. * src/strip.c (INTERNAL_ERROR_MSG): New macro that takes a message string to display. (INTERNAL_ERROR): Use INTERNAL_ERROR_MSG with elf_errmsg (-1). (remove_debug_relocations): Check the sh_link referenced section is real and isn't a SHT_NOBITS section. https://sourceware.org/bugzilla/show_bug.cgi?id=32673 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/32655] eu-readelf SEGV (buffer over read) in handle_dynamic_symtab (src/readelf.c:2903)
https://sourceware.org/bugzilla/show_bug.cgi?id=32655 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit b38e562a4c907e08171c76b8b2def8464d5a104a Author: Mark Wielaard Date: Sun Feb 9 00:07:13 2025 +0100 readelf: Handle NULL phdr in handle_dynamic_symtab A corrupt ELF file can have broken program headers, in which case gelf_getphdr returns NULL. This could crash handle_dynamic_symtab while searching for the PT_DYNAMIC phdr. Fix this by checking whether gelf_phdr returns NULL. * src/readelf.c (handle_dynamic_symtab): Check whether gelf_getphdr returns NULL. https://sourceware.org/bugzilla/show_bug.cgi?id=32655 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/32654] eu-readelf SEGV (head-buffer-overread) in process_symtab (src/readelf.c:2654)
https://sourceware.org/bugzilla/show_bug.cgi?id=32654 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Mark Wielaard --- commit 5e5c0394d82c53e97750fe7b18023e6f84157b81 Author: Mark Wielaard Date: Sat Feb 8 21:44:56 2025 +0100 libelf, readelf: Use validate_str also to check dynamic symstr data When dynsym/str was read through eu-readelf --dynamic by readelf process_symtab the string data was not validated, possibly printing unallocated memory past the end of the symstr data. Fix this by turning the elf_strptr validate_str function into a generic lib/system.h helper function and use it in readelf to validate the strings before use. * libelf/elf_strptr.c (validate_str): Remove to... * lib/system.h (validate_str): ... here. Make inline, simplify check and document. * src/readelf.c (process_symtab): Use validate_str on symstr_data. https://sourceware.org/bugzilla/show_bug.cgi?id=32654 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/32650] eu-readelf SEGV (illegal read access) in __libdw_thread_tail(libdw/libdw_alloc.c:112)
https://sourceware.org/bugzilla/show_bug.cgi?id=32650 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Mark Wielaard --- commit 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753 Author: Mark Wielaard Date: Sat Feb 8 20:00:12 2025 +0100 libdw: Simplify __libdw_getabbrev and fix dwarf_offabbrev issue __libdw_getabbrev could crash on reading a bad abbrev by trying to deallocate memory it didn't allocate itself. This could happen because dwarf_offabbrev would supply its own memory when calling __libdw_getabbrev. No other caller did this. Simplify the __libdw_getabbrev common code by not taking external memory to put the abbrev result in (this would also not work correctly if the abbrev was already cached). And make dwarf_offabbrev explicitly copy the result (if there was no error or end of abbrev). * libdw/dwarf_getabbrev.c (__libdw_getabbrev): Don't take Dwarf_Abbrev result argument. Always just allocate abb when abbrev not found in cache. (dwarf_getabbrev): Don't pass NULL as last argument to __libdw_getabbrev. * libdw/dwarf_tag.c (__libdw_findabbrev): Likewise. * libdw/dwarf_offabbrev.c (dwarf_offabbrev): Likewise. And copy abbrev into abbrevp on success. * libdw/libdw.h (dwarf_offabbrev): Document return values. * libdw/libdwP.h (__libdw_getabbrev): Don't take Dwarf_Abbrev result argument. https://sourceware.org/bugzilla/show_bug.cgi?id=32650 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
☝ Buildbot (Sourceware): elfutils - retry lost connection 'grep PACKAGE_VERSION ...' (exception) (main)
A retry build has been detected on builder elfutils-debian-ppc64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#/builders/63/builds/447 Build state: retry lost connection 'grep PACKAGE_VERSION ...' (exception) Revision: 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753 Worker: debian-ppc64 Build Reason: (unknown) Blamelist: Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/447/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/447/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/447/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#/builders/63/builds/447/steps/4/logs/config_log - 5: get version ( exception ) Logs: - stdio: https://builder.sourceware.org/buildbot/#/builders/63/builds/447/steps/5/logs/stdio - cancelled: https://builder.sourceware.org/buildbot/#/builders/63/builds/447/steps/5/logs/cancelled - err.text: https://builder.sourceware.org/buildbot/#/builders/63/builds/447/steps/5/logs/err_text - err.html: https://builder.sourceware.org/buildbot/#/builders/63/builds/447/steps/5/logs/err_html
