Launchpad has imported 8 comments from the remote bug at https://sourceware.org/bugzilla/show_bug.cgi?id=34468.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers. ------------------------------------------------------------------------ On 2026-08-02T03:09:16+00:00 Bmenrigh wrote: Created attachment 16896 Small example ELF to demonstrate corruption steps. When editing a section, libelf when using ELF_C_RDWR can overwrite the section gap immediately preceding the sectioning being edited. If there is critical information in this section gap, it may be destroyed. The problem doesn't arise with ELF_C_RDWR_MMAP, which properly skips over the gap. Attached is libelf-gap-reproducer.so that has been built to lead to the right conditions. Specifically: Make a copy $ cp libelf-gap-reproducer.so test.so Check than the binary is as expected $ readelf -SW test.so Note that .shstrtab is last [ 6] .shstrtab STRTAB 0000000000000000 000280 000041 00 0 0 1 Now update the elf with patchelf in a way that causes patchelf to relocated a bunch of sections. We can do this by updating DT_SONAME to be a lot longer than it currently is: $ patchelf --set-soname longexamplename test.so Confirm that the relocations have happened: $ readelf -SW test.so Notice now .note.gnu.build-id comes after .shstrtab: [ 1] .shstrtab STRTAB 0000000000000000 000280 000041 00 0 0 1 [ 2] .note.gnu.build-id NOTE 0000000000002000 001000 000024 00 A 0 0 4 Now we update .note.gnu.build-id using debugedit which in turn uses libelf to do the edit, using ELF_C_RDWR which will overwrite the preceding .shstrtab: $ debugedit -i -s somenewseed test.so Now the binary is corrupted: readelf -SW test.so <everything reported null/no strings> readelf: Error: no .dynamic section in the dynamic segment Some testing shows that updating debugedit to use ELF_C_RDWR_MMAP instead avoids the issue. Looking at the libelf code, there is a function fill_mmap(...) in elf32_updatefile.c which appears to be the correct logic. Probably there needs to be a corresponding fill_file(...) that does the same thing whenever ELF_C_RDWR is being used instead. This came up in Gentoo bug 964356: https://bugs.gentoo.org/964356 Reply at: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2169676/comments/0 ------------------------------------------------------------------------ On 2026-08-11T02:40:41+00:00 Bmenrigh wrote: While looking into the possibility of working around this bug by switching debugedit to us the ELF_C_RDWR_MMAP writer, we ran into correctness issues with that writer too. See attachment 968690 in the linked Gentoo bug. It seems that when section headers get relocated, not all of the headers are properly marked as dirty and written back with the MMAP writer. Reply at: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2169676/comments/1 ------------------------------------------------------------------------ On 2026-08-18T19:49:45+00:00 Mark J. Wielaard wrote: Looks like you are right about the "fill" being applied wrongly. At least I can replicate the issue with your example and just commenting out the "fill" call seems to not corrupt the ELF structure. I'll see if replicating the "magic" in fill_mmap makes sense. I do note that debugedit in general might not handle mixed allocated and unallocated sections. It should work for this particular case because no sections get changed in size. But once there are .debug sections to be rewritten having unallocated sections before the allocated sections might trip up debugedit (so we might also have a debugedit bug). Reply at: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2169676/comments/2 ------------------------------------------------------------------------ On 2026-09-17T18:14:34+00:00 Antiq-hofer wrote: I believe we could have a workaround / temporary fix like this > what I tested out: imho we could indeed use the mmap writer here, because the read/write one corrupts the bytes before an edited section, as Brandon pointed out. but additionally in the second change we can elf_flagshdr the section 0 dirty in a separate call since the loop's iterator skips it; and then in the third take we can elf_flagshdr every section header as dirty in the loop so the moved header table is written onto it in full. I did this in order to make the mmap writer copy every header to the new e_shoff so that no slot in the relocated table is left with leftover file contents. --- a/tools/debugedit.c +++ b/tools/debugedit.c @@ -3580,7 +3580,7 @@ if (dest_dir == NULL && (!do_build_id || no_recompute_build_id)) elf = elf_begin (fd, ELF_C_READ, NULL); else - elf = elf_begin (fd, ELF_C_RDWR, NULL); + elf = elf_begin (fd, ELF_C_RDWR_MMAP, NULL); if (elf == NULL) { error (0, 0, "cannot open ELF file: %s", elf_errmsg (-1)); @@ -4079,6 +4079,11 @@ } /* Now adjust any sizes and offsets for the unallocated sections. */ + { + Elf_Scn *zscn = elf_getscn (elf, 0); + if (zscn != NULL) + elf_flagshdr (zscn, ELF_C_SET, ELF_F_DIRTY); + } scn = NULL; while ((scn = elf_nextscn (elf, scn)) != NULL) { @@ -4087,6 +4092,8 @@ if (shdr == NULL) error (1, 0, "Couldn't get shdr: %s", elf_errmsg (-1)); + elf_flagshdr (scn, ELF_C_SET, ELF_F_DIRTY); + /* A bug in elfutils before 0.169 means we have to write out all section data, even when nothing changed. https://sourceware.org/bugzilla/show_bug.cgi?id=21199 */ all 58 tests turn out ok now, for the moment I have not seen any negative effects; I know it doesn't cover libelf issue entirely, but at least there's nothing else breaking hopefully and treats the header table relocation issue. also no longer any truncation of files on gentoo either. ( apologies for short dyslexia ) Reply at: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2169676/comments/3 ------------------------------------------------------------------------ On 2026-10-06T11:42:37+00:00 Benjamin Drung wrote: We hit the same bug in Ubuntu: https://launchpad.net/bugs/2169676 We noticed that failure when building those packages: * telemetry * glew * eccodes Maybe more packages are affected by that. Thanks Jaeger Hofer for the proposed workaround. I have successfully tested it with telemetry. I'll apply that workaround for Ubuntu until the issue is properly fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2169676/comments/9 ------------------------------------------------------------------------ On 2026-10-06T13:57:19+00:00 Antiq-hofer wrote: (In reply to Benjamin Drung from comment #4) > We hit the same bug in Ubuntu: https://launchpad.net/bugs/2169676 > > We noticed that failure when building those packages: > > * telemetry > * glew > * eccodes > > Maybe more packages are affected by that. > > Thanks Jaeger Hofer for the proposed workaround. I have successfully tested > it with telemetry. I'll apply that workaround for Ubuntu until the issue is > properly fixed. Hello. I checked and saw the testings done by Sebastian; I have only one request when the implementation will happen: do offer the appropriate credit (email and name) and details (OS / dependencies) where my proposed workaround patch has been tested so if there are any requests from my side to fix additional issues I can reply accordingly. Thank you. Reply at: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2169676/comments/13 ------------------------------------------------------------------------ On 2026-10-06T14:20:23+00:00 Antiq-hofer wrote: (In reply to Jaeger Hofer from comment #5) > (In reply to Benjamin Drung from comment #4) > > We hit the same bug in Ubuntu: https://launchpad.net/bugs/2169676 > > (...) > > Hello. I checked and saw the testings done by Sebastian; I have only one > request when the implementation will happen: do offer the appropriate credit > (email and name) and details (OS / dependencies) where my proposed > workaround patch has been tested so if there are any requests from my side > to fix additional issues I can reply accordingly. > Sebastian Bacher's change here (from elfutils bug #2169676) in my proposed workaround: - elf = elf_begin (fd, ELF_C_RDWR, NULL); + elf = elf_begin (fd, dest_dir == NULL ? ELF_C_RDWR_MMAP : ELF_C_RDWR, NULL); does fix my regression. The rest seems to be for the moment fine. But I still recommend reports to happen here first at least so we know what to do and what to fix :-) Reply at: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2169676/comments/14 ------------------------------------------------------------------------ On 2026-10-06T15:19:03+00:00 Benjamin Drung wrote: It would be useful to add two test cases to debugedit: * one test case for triggering the bug described here * one test case for the workaround regression found by Sebastian Reply at: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2169676/comments/15 ** Changed in: elfutils Status: Unknown => In Progress ** Changed in: elfutils Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2169676 Title: libelf elf_update(ELF_C_WRITE) with ELF_F_LAYOUT corrupts section headers when the section header table is not at the end of the file (patchelf output); breaks debugedit To manage notifications about this bug go to: https://bugs.launchpad.net/elfutils/+bug/2169676/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
