https://sourceware.org/bugzilla/show_bug.cgi?id=34049
--- Comment #2 from Takao Sato <takaosato1997 at gmail dot com> --- (In reply to Alan Modra from comment #1) > Note that the bug does not reproduce when linking to xcoff output with the > testcase input being the first input file, because > xcoff_link_create_extra_sections adds a number of sections to the first bfd. > That increases the section count enough to prevent the overflow. Thank you for the analysis, Alan. Confirmed — my PoC reproduces via: ld -o /dev/null crash_min.o The output target in this invocation is not XCOFF (it resolves to the default BFD target, ELF on my build), so xcoff_link_create_extra_sections is not called and no extra sections are added to the first BFD. That is the path where the overflow occurs. To summarize the narrower reproduction condition: - Triggers: ld with non-XCOFF output target (e.g. -o /dev/null, ELF output) processing a malformed XCOFF .o where a section is dropped during parsing but retains its original target_index. - Does not trigger: ld with XCOFF output target and the crafted file as the first input, because xcoff_link_create_extra_sections raises section_count past the stale target_index. The root mismatch between section_count and target_index remains, and the bounds check in Option A (or Option B) would close both paths. Is a fix planned, or is this considered low-priority given the narrowed attack surface? -- You are receiving this mail because: You are on the CC list for the bug.
