* Re: [yocto] linux-yocto CVEs in need of triage
2026-06-29 19:33 linux-yocto CVEs in need of triage Paul Barker
@ 2026-07-22 14:45 ` Randy MacLeod
2026-07-23 12:15 ` Navuduri, Venkata Adhitya
2026-08-02 14:33 ` Junjie Cao
1 sibling, 1 reply; 5+ messages in thread
From: Randy MacLeod @ 2026-07-22 14:45 UTC (permalink / raw)
To: yocto, paul, openembedded-core@lists.openembedded.org,
linux-yocto, Navuduri, Venkata
Cc: Dmitriy Korovkin
[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]
On 2026-06-29 15:33, Paul Barker via lists.yoctoproject.org wrote:
> Hi all,
>
> We would appreciate help triaging the following CVEs filed against the
> Linux Kernel, which therefore affect linux-yocto.
>
> Each of these is missing an upstream fix version in the CVE data, so
> they show as unresolved in our CVE metrics. However, they may well be
> fixed already in the kernel versions that we ship. So we need some help
> to determine the appropriate upstream fix versions.
>
> For each CVE, at a minimum we need to know if they are resolved in the
> mainline kernel, and if so then which release they were resolved in. A
> pointer to the exact upstream commit resolving the issue would be
> preferred. This may involve a bit of investigation, so please share the
> information you find that proves that a CVE is resolved in a particular
> kernel version.
>
> Once you've investigated a particular CVE, if it is resolved upstream
> then please send a patch to update the linux-yocto cve-exclusion.inc
> file with the appropriate information. See recent commits to this file
> for examples of what we need, e.g:
> https://git.openembedded.org/openembedded-core/commit/?id=ded28ca69b326e51ac5cf363f06c6f0931a9c1bd
>
> Once we've got patches merged into the master branch, we can look at
> backporting to wrynose & scarthgap as appropriate.
>
> The open linux-yocto CVEs lacking an upstream fix version and not
> currently tracked in cve-exclusion.inc are:
>
> - CVE-2019-14899
> - CVE-2021-3714
> - CVE-2021-3864
> - CVE-2022-0400
> - CVE-2022-1247
> - CVE-2022-4543
> - CVE-2023-3397
> - CVE-2023-3640
> - CVE-2023-4010
> - CVE-2023-6238
> - CVE-2023-6240
Venkata, who goes by Adhitya, has looked into all of these issues.
He's found one CVEs:
CVE-2023-3640 - x86 cpu_entry_area KASLR bypass.
that we can backport via linux-stable.
He has notes on the rest of the CVEs and will reply himself shortly.
../Randy
>
> Best regards,
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#66616):https://lists.yoctoproject.org/g/yocto/message/66616
> Mute This Topic:https://lists.yoctoproject.org/mt/120036383/3616765
> Group Owner:yocto+owner@lists.yoctoproject.org
> Unsubscribe:https://lists.yoctoproject.org/g/yocto/unsub [randy.macleod@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
--
# Randy MacLeod
# Wind River Linux
[-- Attachment #2: Type: text/html, Size: 3848 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [yocto] linux-yocto CVEs in need of triage
2026-06-29 19:33 linux-yocto CVEs in need of triage Paul Barker
2026-07-22 14:45 ` [yocto] " Randy MacLeod
@ 2026-08-02 14:33 ` Junjie Cao
1 sibling, 0 replies; 5+ messages in thread
From: Junjie Cao @ 2026-08-02 14:33 UTC (permalink / raw)
To: linux-yocto
Cc: yocto, openembedded-core, Paul Barker, Randy MacLeod,
Navuduri, Venkata Adhitya
Hi Paul,
I have independently triaged the CVEs on this list other than
CVE-2023-3640, which Adhitya already covered. For the seven with a
conclusive status I have sent a patch for cve-exclusion.inc to the
OE-core list ("cve-exclusion: set status for 7 kernel CVEs lacking
upstream fix data"). Summary of all verdicts below; every claimed
commit was verified against mainline history (linux-next 20260727),
and I note explicitly where a tie is my inference rather than a
distro/CNA statement.
Fixed upstream (nobody has connected the dots yet):
* CVE-2022-1247 (rose_connect() refcount race): actually fixed in
v6.17 by d860d1faa6b2 ("net: rose: convert 'use' field to
refcount_t") plus da9c9c877597, from Takamitsu Iwai's Aug-2025
series. The commit message describes the CVE's premise almost
verbatim ("The 'use' field in struct rose_neigh is used as a
reference counter but lacks atomicity") and the diff removes the
exact rose->neighbour->use++ in rose_connect(). Backported to
6.1.y/6.6.y/6.12.y/6.16.y in the 2025-09-02 stable round. The whole
rose/hamradio subsystem was then removed in v7.1 (dd8d4bc28ad7), so
>= v7.1 is unaffected by construction. Ubuntu/Debian/Red Hat
trackers all still show this as open - it may be worth feeding the
correction back to them. Caution: the two 2022 Duoming Zhou rose
patches referenced by Ubuntu's tracker fix different rose bugs and
are not this CVE's fix.
* CVE-2023-4010: the function named by the CVE (usb_giveback_urb())
does not exist in the kernel. The reporter's own PoC repo output
points at drivers/media/rc/imon.c: an unthrottled URB resubmit loop
producing a printk flood on -EPROTO (Ubuntu triage: "There is no
system lockup happening"). That loop was stopped by eecd203ada43
("media: imon: make send_packet() more robust") in v6.18. The commit
carries no CVE reference, so this tie is inferred - flagged as such
in the patch; treating it as "disputed" instead would also be
defensible.
No fix exists or is planned (proposed as upstream-wontfix/disputed in
the patch):
* CVE-2019-14899: weak host model property, config-only mitigations
(wg-quick ships a firewall rule); NVD CPE is unversioned so it can
never match a fixed version.
* CVE-2021-3714: KSM dedup side channel; Red Hat bz#1931327 CLOSED
WONTFIX. Note CONFIG_KSM=y is set in kernel-cache (intel-x86 BSP and
paravirt_kvm), but ksmd is off by default and pages must opt in via
MADV_MERGEABLE/PR_SET_MEMORY_MERGE.
* CVE-2021-3864: setuid coredump LPE; the Waiman Long and Wander
Costa fix attempts (Dec 2021/Jan 2022) were rejected or fizzled and
the flagged fs/exec.c logic is unchanged today. Only exploitable
with a relative kernel.core_pattern; happy to drop this entry if you
would rather keep it visible for sysvinit images that ship the
kernel default "core" pattern.
* CVE-2022-0400 (net/smc OOB read): never substantiated - Red Hat
bz#2044575 CLOSED NOTABUG, SUSE bsc#1195329 RESOLVED INVALID, Debian
"non issue"; the originating report (bz#2040604) was never made
public and the CNA recorded no affected version.
* CVE-2022-4543 ("EntryBleed"): entry text is still cloned
_PAGE_GLOBAL into user page tables (arch/x86/mm/pti.c); upstream and
Debian position is that KASLR is not a boundary against local
attackers. One clarification worth recording since the two are often
confused: 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area",
v6.2) is the fix for the cpu_entry_area issue - i.e. CVE-2023-3640,
as Adhitya identified - and does not address EntryBleed, which leaks
the KASLR base via entry_SYSCALL_64 itself.
Genuinely unfixed - deliberately NOT added to cve-exclusion.inc, so
they stay visible in the metrics:
* CVE-2023-3397: real subsystem is JFS (txEnd()/lmLogClose() UAF),
not slub. The only proposed fix (lore
20230515095956.17898-1-zyytlz.wz@163.com) was withdrawn by its
author after review; the racy code is unchanged at HEAD and syzbot
was still reproducing slab-use-after-free in txEnd in June 2026.
* CVE-2023-6238 (NVMe passthrough metadata DMA overflow): a
mitigation ("nvme: remove unprivileged passthrough support",
20231016060519.231880-1-joshi.k@samsung.com) was applied to nvme-6.6
and then explicitly backed out by Keith Busch, over Christoph
Hellwig's objection ("We leave an exploitable hole in"); nothing
re-landed and nvme_map_user_request() still passes the user
meta_len through without an NLB*MS cross-check. One actionable
nuance: the exposure was introduced by 855b7717f44b in v6.2, so
linux-yocto branches < v6.2 (5.15, 6.1) are not affected - Debian
independently reached the same conclusion.
* CVE-2023-6240 ("Marvin" RSA timing oracle): nothing to do with
Marvell or s390; the leaky code is the generic
pkcs1pad_decrypt_complete() in crypto/rsa-pkcs1pad.c, which still
branches on secret-derived data at HEAD. Fixed only in RHEL
downstream (RHSA-2024:2758 etc.); Ubuntu notes "appears unfixed in
upstream as of 2024.08.24". Practical exposure needs a service
driving KEYCTL_PKEY_DECRYPT with a long-lived key, which is narrow,
but the primitive is present.
I kept CVE-2023-3640 out of the patch since Adhitya has it in hand;
the 4543-vs-3640 note above is just so the two KASLR CVEs don't get
cross-wired in the data later.
Happy to adjust any of the statuses or wording, and to help with the
wrynose/scarthgap backports once the master patch is settled.
Best regards,
Junjie Cao
^ permalink raw reply [flat|nested] 5+ messages in thread