linux-yocto CVEs in need of triage

linux-yocto CVEs in need of triage

[Paul Barker]

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

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

Best regards,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [yocto] linux-yocto CVEs in need of triage

[Randy MacLeod]

[-- 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 --]

Re: [yocto] linux-yocto CVEs in need of triage

[Navuduri, Venkata Adhitya]

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

On 7/22/26 10:45, MacLeod, Randy wrote:
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,










--
# Randy MacLeod
# Wind River Linux

Hello,

Regarding CVE-2023-3640 (x86 cpu_entry_area KASLR bypass, CVSS 7.8):
The mainline fix is commit 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area") by Peter Zijlstra, merged in v6.2-rc1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e3d26b5e5f


So, for Yocto releases shipping kernel >=6.2 version this fix is already present. This fix needs back porting to kernel <6.2

For now, I can prepare a patch to add this CVE in the cve-exclusion.inc to stop the CVE tool from reporting on this.


Best Regards,
Adhitya

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

Re: [OE-core] [yocto] linux-yocto CVEs in need of triage

[Paul Barker]

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

On Thu, 2026-07-23 at 12:15 +0000, Navuduri, Venkata Adhitya via
lists.openembedded.org wrote:
> Hello,
> 
> Regarding CVE-2023-3640 (x86 cpu_entry_area KASLR bypass, CVSS 7.8):
> The mainline fix is commit 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area") by Peter Zijlstra, merged in v6.2-rc1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e3d26b5e5f
> 
> 
> So, for Yocto releases shipping kernel >=6.2 version this fix is already present. This fix needs back porting to kernel <6.2
> 
> For now, I can prepare a patch to add this CVE in the cve-exclusion.inc to stop the CVE tool from reporting on this.
> 

Hi Adhitya,

Please send a patch to update cve-exclusion.inc, in the commit message
please include any information or references you have to to identify
commit 97e3d26b5e5f as the fix.

Best regards,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [yocto] linux-yocto CVEs in need of triage

[Junjie Cao]

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