Re: binutils: disposition for XCOFF CVEs 2026-3441/3442/6846

[Randy MacLeod <randy.macleod@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 3854 bytes --]

Hi Sunil,


On 2026-06-16 09:12, Dora, Sunil Kumar wrote:
> Hi,
>
> I'm looking at three XCOFF CVEs against binutils 2.46
2.46.1 is tagged, please do an upgrade for oe-core/master and wrynose 
once master is merged.

> and want to check the preferred disposition before sending anything.
> All three are in the XCOFF code (xcofflink.c / coff-rs6000.c):
>
> CVE-2026-3441 <https://nvd.nist.gov/vuln/detail/CVE-2026-3441>, 3442 
> <https://nvd.nist.gov/vuln/detail/CVE-2026-3442><https://nvd.nist.gov/vuln/detail/CVE-2026-3442>— 
> both fixed by commit c2bf7de1eb7 
> <https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=c2bf7de1eb77a91d7a3c86d56408bf57de540faf><https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=c2bf7de1eb77a91d7a3c86d56408bf57de540faf>("xcofflink 
> buffer overflows"). One commit covers both: the x_scnlen bounds check 
> is 3441, the r_symndx check is 3442. No CVE in the commit message 
> (Modra doesn't add them), but the diff matches the Red Hat bug 
> descriptions exactly (bugs 2443826 and 2443828).
It's a small patch
binutils.git on master
❯ git show c2bf7de1eb7 | diffstat
  xcofflink.c |   10 ++++------
  1 file changed, 4 insertions(+), 6 deletions(-)

and 'just' does some casts to avoid buffer overflows but as you explain 
is unlikely to impact users.

Just to ensure that no one else has the same questioning, I'd send a PR 
to binutils upstream to bring
that commit to:
    binutils-2_46-branch
and then either wait for 2.46.2 to be released or add the commit as a 
CVE-20226-XXXXX.patch.

That works for master, wrynose, and it's probably a good approach for 
older branches too.

Does that make sense and seem reasonable ?


../Randy



>
> CVE-2026-6846 <https://nvd.nist.gov/vuln/detail/CVE-2026-6846>  - 
> fixed by 7a089e03 
> <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7a089e0302382f4d4e077941156e1eaa68d01393><https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7a089e0302382f4d4e077941156e1eaa68d01393>  
> (PR34049 <https://sourceware.org/bugzilla/show_bug.cgi?id=34049>).
>
> None of these are in the 2.46 release (checked against binutils-2_46), 
> so it'd be a backport, same as how CVE-2026-4647 was handled in 
> 42115ea9 
> <https://git.openembedded.org/openembedded-core/commit/meta/recipes-devtools/binutils?id=42115ea98a6aed68120ec1df703f07905f7dddd9>.
>
> One thing I checked while looking at this: only binutils-native 
> actually builds the XCOFF backend (it gets --enable-targets=all). The 
> target, cross, crosssdk and cross-canadian variants are ELF+PE only - 
> confirmed with objdump -i on native and bfd_backends on the others. 
> So, the vulnerable code is present only in native, a build-host tool. 
> That made me unsure whether not-applicable-config fits, since the code 
> isn't entirely absent from the recipe.
>
> There's also the upstream side: binutils SECURITY.txt was updated last 
> month (commit e1428067748 
> <https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=e1428067748d6b713637241855d1c315fb657c8b>) 
> to say a bug from crafted input has to cross a trust boundary to count 
> as a security bug (Discussion:RFC Thread 
> <https://sourceware.org/pipermail/binutils/2026-May/149207.html>). 
> These three are all crafted-XCOFF OOB issues in tools that assume 
> trusted input, so by that policy they arguably aren't security bugs at 
> all.
>
> So, I'm not sure which way to go:
>
>  *
>     backport the fixes (like 4647), or
>  *
>     mark CVE_STATUS as disputed, given the updated upstream policy.
>
>
> Happy to send the backport patches if that's preferred - c2bf7de1 
> applies cleanly on the 2.46 branch. Just wanted to check the direction 
> first.
>
> Thanks,
> Sunil Dora


-- 
# Randy MacLeod
# Wind River Linux

[-- Attachment #2: Type: text/html, Size: 11483 bytes --]