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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#238965):
https://lists.openembedded.org/g/openembedded-core/message/238965
Mute This Topic: https://lists.openembedded.org/mt/119832836/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
