Heap-buffer-overflow WRITE in xcoff_link_add_symbols() in bfd/xcofflink.c. Triggered by malformed XCOFF object file during linking. Fixed upstream by Alan Modra. Public reference: https://sourceware.org/bugzilla/show_bug.cgi?id=34049 Affects binutils <= 2.46.
There's no security issue here, please review the binutils and gdb security policies: https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=binutils/SECURITY.txt;hb=HEAD https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/SECURITY.txt;hb=HEAD Same for CVE-2026-6845, please lets not issue CVE numbers for binutils and gdb like this, it's just a waste of time for everyone.
I want to address the security policy concern directly, because binutils/SECURITY.txt, which was cited here, supports this report rather than dismissing it. The policy defines a security bug as one where "the programs themselves might be tricked into a direct compromise of security." This bug meets that definition. ld processes a crafted XCOFF object file and undergoes a confirmed two-phase heap corruption primitive. Phase 1 writes heap pointers from xcoff_read_internal_relocs() and bfd_zmalloc() out of bounds into the prev_size and size fields of the adjacent glibc heap chunk at lines 1416 and 1420, corrupting its metadata. Phase 2 calls free() on those OOB-stored pointers at lines 2328, 2347, 2362 and 2363. This is not theoretical. In a standard release build without ASAN, glibc aborts with "double free or corruption (out)" at line 2328 when free() validates the chunk whose header was corrupted in Phase 1. A heap metadata corruption primitive that reaches free() of attacker-influenced pointers in a release build is not a quality issue. It is precisely what the policy was written to cover. The commit message for 7a089e03 adds a technically significant point. Alan Modra documented that the root cause is BFD's own internal behavior: coff_set_alignment_hook removes sections during normal XCOFF parsing, which causes target_index to exceed section_count regardless of whether the input was crafted with malicious intent. The vulnerable condition does not require an attacker to do anything sophisticated. It arises from the parser's own logic. A garbage-in garbage-out framing does not apply when the garbage is produced internally by the tool itself. On process: the same SECURITY.txt cited here states that downstream security teams handle vulnerability rating and CVE assignment, and lists secalert as the designated contact. Alan Modra pointed me to exactly that in comment 6 of the upstream bug. I contacted the designated team and followed the documented process in full. What happened next is also on record. On April 22, Red Hat Product Security assigned CVE-2026-6846, documented it as "Arbitrary code execution via malformed XCOFF object file processing", moved the bug from vulnerability-draft to vulnerability status, and expanded tracking to eight affected components across Fedora and EPEL. All of that happened before this comment was posted. Calling this a waste of time is a characterization that conflicts with the actions already taken by the security team responsible for making that determination. The technical documentation for this report includes ASAN output with full stack trace, GDB-confirmed values at the crash point showing abfd->section_count=1 and o->target_index=2, a minimized 100-byte reproducer generated with AFL++, and two proposed fixes. Option B, allocating based on max target_index rather than section_count, is exactly what landed in master. The fix is in 2.47. The report is correct, the process was followed correctly, and the CVE exists because the designated security team reviewed it and determined it warranted one.
(In reply to Takao Sato from comment #6) > I want to address the security policy concern directly, because > binutils/SECURITY.txt, > which was cited here, supports this report rather than dismissing it. > > The policy defines a security bug as one where "the programs themselves > might be > tricked into a direct compromise of security." This bug meets that > definition. ld > processes a crafted XCOFF object file and undergoes a confirmed two-phase > heap > corruption primitive. I'm one of the people involved in writing that policy and that line needs to be read in the context of trust boundaries, i.e. a bug constitutes a security issue if it results in a trust boundary crossing, e.g. escalation of privileges or being able to execute code as another user (e.g. /tmp races). In general, compilers and linkers assume trusted input, but since you pointed out, I agree that the binutils security policy doesn't make that clear enough (the gcc one does[1], for example and even llvm[2]), so @Nick, looks like you need to make an explicit clarification in the policy like gcc has. [1] https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=SECURITY.txt;hb=HEAD [2] https://llvm.org/docs/Security.html#what-is-considered-a-security-issue > On process: the same SECURITY.txt cited here states that downstream security > teams > handle vulnerability rating and CVE assignment, and lists > secalert as > the designated contact. Alan Modra pointed me to exactly that in comment 6 > of the > upstream bug. I contacted the designated team and followed the documented > process > in full. What happened next is also on record. On April 22, Red Hat Product > Security > assigned CVE-2026-6846, documented it as "Arbitrary code execution via > malformed > XCOFF object file processing", moved the bug from vulnerability-draft to > vulnerability > status, and expanded tracking to eight affected components across Fedora and > EPEL. > All of that happened before this comment was posted. Calling this a waste of > time > is a characterization that conflicts with the actions already taken by the > security > team responsible for making that determination. > > The technical documentation for this report includes ASAN output with full > stack > trace, GDB-confirmed values at the crash point showing abfd->section_count=1 > and > o->target_index=2, a minimized 100-byte reproducer generated with AFL++, and > two > proposed fixes. Option B, allocating based on max target_index rather than > section_count, is exactly what landed in master. > > The fix is in 2.47. The report is correct, the process was followed > correctly, > and the CVE exists because the designated security team reviewed it and > determined it warranted one. I'm sorry, I didn't mean to characterize the work that went into finding the bug and reporting it as a waste of time; thank you for the work you're doing here. However, we (the binutils community) have previously agreed that inputs to binutils utilities are essentially considered trusted and as a result, they don't constitute security issues. We've been operating on this principle for some years now and only just noticed that the policy doesn't make it clear enough. Thank you for pointing that out.
(In reply to Siddhesh Poyarekar from comment #7) > (In reply to Takao Sato from comment #6) > > I want to address the security policy concern directly, because > > binutils/SECURITY.txt, > > which was cited here, supports this report rather than dismissing it. > > > > The policy defines a security bug as one where "the programs themselves > > might be > > tricked into a direct compromise of security." This bug meets that > > definition. ld > > processes a crafted XCOFF object file and undergoes a confirmed two-phase > > heap > > corruption primitive. > > I'm one of the people involved in writing that policy and that line needs to > be read in the context of trust boundaries, i.e. a bug constitutes a > security issue if it results in a trust boundary crossing, e.g. escalation > of privileges or being able to execute code as another user (e.g. /tmp > races). In general, compilers and linkers assume trusted input, but since > you pointed out, I agree that the binutils security policy doesn't make that > clear enough (the gcc one does[1], for example and even llvm[2]), so @Nick, > looks like you need to make an explicit clarification in the policy like gcc > has. > > [1] https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=SECURITY.txt;hb=HEAD > [2] https://llvm.org/docs/Security.html#what-is-considered-a-security-issue > > > On process: the same SECURITY.txt cited here states that downstream security > > teams > > handle vulnerability rating and CVE assignment, and lists > > secalert as > > the designated contact. Alan Modra pointed me to exactly that in comment 6 > > of the > > upstream bug. I contacted the designated team and followed the documented > > process > > in full. What happened next is also on record. On April 22, Red Hat Product > > Security > > assigned CVE-2026-6846, documented it as "Arbitrary code execution via > > malformed > > XCOFF object file processing", moved the bug from vulnerability-draft to > > vulnerability > > status, and expanded tracking to eight affected components across Fedora and > > EPEL. > > All of that happened before this comment was posted. Calling this a waste of > > time > > is a characterization that conflicts with the actions already taken by the > > security > > team responsible for making that determination. > > > > The technical documentation for this report includes ASAN output with full > > stack > > trace, GDB-confirmed values at the crash point showing abfd->section_count=1 > > and > > o->target_index=2, a minimized 100-byte reproducer generated with AFL++, and > > two > > proposed fixes. Option B, allocating based on max target_index rather than > > section_count, is exactly what landed in master. > > > > The fix is in 2.47. The report is correct, the process was followed > > correctly, > > and the CVE exists because the designated security team reviewed it and > > determined it warranted one. > > I'm sorry, I didn't mean to characterize the work that went into finding the > bug and reporting it as a waste of time; thank you for the work you're doing > here. However, we (the binutils community) have previously agreed that > inputs to binutils utilities are essentially considered trusted and as a > result, they don't constitute security issues. We've been operating on this > principle for some years now and only just noticed that the policy doesn't > make it clear enough. Thank you for pointing that out. Thank you for the clarification Siddhesh, and for taking the time to explain the community's position on trusted input boundaries. I can see how that principle makes sense in the context of how binutils is typically used. I think the policy update will be really helpful for future reporters who, like me, read the current text and reached a different conclusion in good faith. Happy to have contributed to surfacing that gap at least. Thanks again for the work you and the team put into maintaining these tools.
I have posted a proposed extension to the current wording of the SECURITY.txt document: https://sourceware.org/pipermail/binutils/2026-May/149203.html It is my hope that this will make it clear that bugs that rely upon using fuzzed or hand crafted binaries should not qualify for CVE status unless they can truly be exploited to cause harm to the system.
(In reply to Siddhesh Poyarekar from comment #5) > There's no security issue here, please review the binutils and gdb security > policies: > > https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=binutils/ https://treeshateyou.io > SECURITY.txt;hb=HEAD > https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/SECURITY. > txt;hb=HEAD > > Same for CVE-2026-6845, please lets not issue CVE numbers for binutils and > gdb like this, it's just a waste of time for everyone. You are right that not every binutils/gdb issue represents a high-risk security flaw in practice, and upstream SECURITY policies do matter. But CVE assignment is not meant to reflect only upstream intent—it reflects ecosystem-wide risk management, especially for tools like binutils that are widely used in security-sensitive contexts.
(In reply to Charlotte from comment #10) > But CVE assignment is not meant to reflect only upstream intent—it reflects > ecosystem-wide risk management, especially for tools like binutils that are > widely used in security-sensitive contexts. Please actually read the security policy, it describes precisely how binutils should be used in security-sensitive contexts and it's not just a statement of intent. It is a description of how these tools can be used securely and it is closely linked to actual production usage of binutils tools. Removing that context would mean that each and every bug in each and every application is a security issue, because each and every program can be used in pretty much any context.