[Bug ld/32690] ld internal error (internal error binutils/ld/ldlang.c 6618) with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=32690 --- Comment #10 from Alan Modra --- I think HJ's patch is just papering over the real problem, and likely will result in sections being placed wrongly at the end of the relro segment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32690] ld internal error (internal error binutils/ld/ldlang.c 6618) with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=32690 --- Comment #8 from Sam James --- Thanks H.J. It works. If you need me to, I can try get a source test case, but it will be very time consuming because of the layout of the 2 cases I found so far. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32690] ld internal error (internal error binutils/ld/ldlang.c 6618) with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=32690 --- Comment #9 from H.J. Lu --- (In reply to Sam James from comment #8) > Thanks H.J. It works. If you need me to, I can try get a source test case, > but it will be very time consuming because of the layout of the 2 cases I > found so far. Please try to get a source testcase. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32048] SEGFAULT on arm32 with abnormal page size
https://sourceware.org/bugzilla/show_bug.cgi?id=32048 --- Comment #10 from Claudio Luck --- Please note that due to the abovementioned commit, GNU/Linux is effectively banned from many 32bit arm systems (and some 64bit arm systems with 32bit userland support). Said commit https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1a26a53a0dee39106ba58fcb15496c5f13074652 was made to revert the space increase of binaries introduced by the fix of "relro security issue" https://sourceware.org/bugzilla/show_bug.cgi?id=28824. The commit message shows that there were wrong assumptions at play. Contrary to the commit message, 32bit Kernels with larger pagesizes do exist in commercially available platforms: [~] # uname -a Linux QNAP-NAS 4.2.8 #2 SMP Wed Jan 8 03:49:48 CST 2025 armv7l GNU/Linux [~] # zcat /proc/config.gz | grep PAGE_SIZE CONFIG_ARM_PAGE_SIZE_LARGE=y # CONFIG_ARM_PAGE_SIZE_64KB is not set CONFIG_ARM_PAGE_SIZE_32KB=y # CONFIG_ARM_PAGE_SIZE_4KB is not set CONFIG_ARM_PAGE_SIZE_LARGE_SHIFT=15 Also, it is unclear how the larger binary size is a practical problem in the first place, since compressed root filesystems are ubiquituous (the added padding compresses particularly well). And in the greater context, there seems to be a "more proper" way to eliminate the space increase while also keeping pagesize compatibility: In https://sourceware.org/bugzilla/show_bug.cgi?id=30033#c5 it was mentioned that the mold linker and LLVM had found a better workaround to avoid the space increase (namely to map the boundary page twice) while still supporting all pagesizes. It was concluded that GNU ld could implement the same technique. 1,5 years earlier, though, Fangrui Song in https://sourceware.org/bugzilla/show_bug.cgi?id=30612#c1 stated that "this is nearly infeasible to fix, as long as the alignment still follows max-page-size, as switching to a two-RW-PT_LOAD layout in GNU ld is very difficult." Thus, not expecting an imminent implementation of a "proper" workaround, I politely ask to consider reverting 1a26a53a0dee39106ba58fcb15496c5f13074652. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30612] maxpagesize alignment after relro segment takes up space
https://sourceware.org/bugzilla/show_bug.cgi?id=30612 --- Comment #5 from Dominique Martinet --- (to be clear, I'm not dismissing the issue you pointed at for arm32 and agree that commit is probably best reverted in the short term, I'm just asserting that size increases still cause all sort of headaches for some people and some "better" fix would still be appreciated so this bz ought to be kept open if someone can find time to figure it out. Perhaps if arm32 binaries grow a well someone will be afforded time to look at it again...) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30612] maxpagesize alignment after relro segment takes up space
https://sourceware.org/bugzilla/show_bug.cgi?id=30612 --- Comment #4 from Dominique Martinet --- > Is this truly a practical problem? Virtually every space-constrained system > makes use of compressed firmware images, or has readily access to that > tecnology. We're using plain ext4 for the root file system at $work, as it's not read-only. Since this change I've been pushing for btrfs with compression enabled, but it's a workaround at best. Afaik, container images layers are also stored uncompressed for example, so there's plenty of "at scale" effect too... > I ask, because the alleged "fix" [1] to this space issue introduced a > regression [2] which effectively banned GNU/Linux from systems with larger > pagesizes, which, contrary to the assumption in the commit, exist > commercially and in large numbers. That's not a fix; it wasn't even considered for arm64 because larger pages are known to be used there. The fix was described in #28824 (make multiple mappings), but nobody's gone out of their way to implement it yet (for my part, mostly because the workaround is cheaper to implement and $work priorities aren't aligned with "doing the right thing") -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32690] ld assertion (internal error binutils/ld/ldlang.c 6618) since 73ab3b9825d232f0f3a4ad811e88697f9b9ab162
https://sourceware.org/bugzilla/show_bug.cgi?id=32690 H.J. Lu changed: What|Removed |Added Attachment #15947|0 |1 is obsolete|| --- Comment #13 from H.J. Lu --- Created attachment 15949 --> https://sourceware.org/bugzilla/attachment.cgi?id=15949&action=edit An updated patch commit 73ab3b9825d232f0f3a4ad811e88697f9b9ab162 Author: H.J. Lu Date: Thu Jan 30 08:48:45 2025 +0800 x86-64: Estimate output section layout before sizing dynamic sections triggered this latent issue. It can happen without my change. When lang_size_relro_segment_1 is called, with the following sections in the relro segment: section vma size vma + size .got 0x320268 0xd80 0x320fe8 .dynamic 0x31ffe8 0x280 0x320268 .data.rel.ro 0x2f3020 0x2cfc8 0x31ffe8 .fini_array 0x2f3008 0x8 0x2f3010 .init_array 0x2f3000 0x8 0x2f3008 the initial relro end is 0x321000. The desired relro end is adjusted to 1. 0x320280 for .dynamic 2. 0x32 for .data.rel.ro 3. 0x2f3000 for .fini_array Now the desired relro end is lower than the .fini_array vma + end. In this case, set the desired relro end for the previous section, .init_array, to the aligned end of .fini_array. 4. 0x2f3010 for .init_array. The final relro end becomes 0x2f3008. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32690] ld assertion (internal error binutils/ld/ldlang.c 6618) since 73ab3b9825d232f0f3a4ad811e88697f9b9ab162
https://sourceware.org/bugzilla/show_bug.cgi?id=32690 H.J. Lu changed: What|Removed |Added Attachment #15949|0 |1 is obsolete|| --- Comment #14 from H.J. Lu --- Created attachment 15950 --> https://sourceware.org/bugzilla/attachment.cgi?id=15950&action=edit A fixed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32698] New: Null pointer dereference in bfd/tekhex.c
https://sourceware.org/bugzilla/show_bug.cgi?id=32698 Bug ID: 32698 Summary: Null pointer dereference in bfd/tekhex.c Product: binutils Version: 2.44 Status: UNCONFIRMED Severity: critical Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: shiyuyuranzh at gmail dot com Target Milestone: --- Created attachment 15952 --> https://sourceware.org/bugzilla/attachment.cgi?id=15952&action=edit Vulnerability paths and examples I have found a potential null pointer dereference bug in bfd/tekhex.c and would like to report it to the maintainers. This vulnerability has the potential to cause unexpected application behavior, crashes. Can you please help me check it? Thank you for your effort and patience! Below is the execution sequence of the program that may produce null pointer dereference bug.The specific paths are shown in the attachment. First, in the file tekhex.c, the function find_chunk returns NULL on line 334. Second, the function insert_byte calls the function find_chunk on line 349, causing the variable d to be assigned NULL. Third, d is dereferenced on lines 351 and 352, resulting in a null pointer dereference vulnerability. In addition to this, other examples of calling find_chunk and checking if its return value is NULL are shown in the attached image at the bottom. For example, in the file bfd/tekhex.c, the function move_section_contents calls the function find_chunk on line 655, followed by a check on whether d is NULL on line 661. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32690] ld assertion (internal error binutils/ld/ldlang.c 6618) since 73ab3b9825d232f0f3a4ad811e88697f9b9ab162
https://sourceware.org/bugzilla/show_bug.cgi?id=32690 Sam James changed: What|Removed |Added Summary|ld internal error (internal |ld assertion (internal |error binutils/ld/ldlang.c |error binutils/ld/ldlang.c |6618) with LTO |6618) since ||73ab3b9825d232f0f3a4ad811e8 ||8697f9b9ab162 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32690] ld internal error (internal error binutils/ld/ldlang.c 6618) with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=32690 --- Comment #11 from Sam James --- I should have a testcase soon. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32690] ld internal error (internal error binutils/ld/ldlang.c 6618) with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=32690 --- Comment #12 from Sam James --- Created attachment 15948 --> https://sourceware.org/bugzilla/attachment.cgi?id=15948&action=edit binutils-32690-src1.tar.xz This is a standalone testcase. I'm reducing it now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32613] .cfi_escape usability
https://sourceware.org/bugzilla/show_bug.cgi?id=32613 Indu Bhagat changed: What|Removed |Added CC||indu.bhagat at oracle dot com --- Comment #1 from Indu Bhagat --- Can you elaborate on "Which in turn requires them to either be constants, or to involve perhaps pretty complex expressions." ? It seemed to me that the current interface only allows a byte sequence after .cfi_escape.. Also does this mean that GAS will need to validate the contents specified in .cfi_escape too? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30612] maxpagesize alignment after relro segment takes up space
https://sourceware.org/bugzilla/show_bug.cgi?id=30612 Claudio Luck changed: What|Removed |Added CC||c.luck at datact dot ch --- Comment #3 from Claudio Luck --- Is this truly a practical problem? Virtually every space-constrained system makes use of compressed firmware images, or has readily access to that tecnology. Thus, I wouldn't expect the accumulated binary size to actually consume significantly more physical storage. I ask, because the alleged "fix" [1] to this space issue introduced a regression [2] which effectively banned GNU/Linux from systems with larger pagesizes, which, contrary to the assumption in the commit, exist commercially and in large numbers. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1a26a53a0dee39106ba58fcb15496c5f13074652 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=32048 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32048] SEGFAULT on arm32 with abnormal page size
https://sourceware.org/bugzilla/show_bug.cgi?id=32048 Sam James changed: What|Removed |Added CC||nickc at redhat dot com, ||rearnsha at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32698] Null pointer dereference in bfd/tekhex.c
https://sourceware.org/bugzilla/show_bug.cgi?id=32698 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Severity|critical|normal -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32698] Null pointer dereference in bfd/tekhex.c
https://sourceware.org/bugzilla/show_bug.cgi?id=32698 Alan Modra changed: What|Removed |Added Last reconfirmed||2025-02-15 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32048] SEGFAULT on arm32 with abnormal page size
https://sourceware.org/bugzilla/show_bug.cgi?id=32048 Thomas De Schampheleire changed: What|Removed |Added CC||patrickdepinguin at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
