[OE-core][PATCH v3 0/9] cve-exclusions: triage nine kernel CVEs lacking upstream fix data

[OE-core][PATCH v3 0/9] cve-exclusions: triage nine kernel CVEs lacking upstream fix data

[Junjie Cao]

This is v3 of the kernel CVE triage from Paul Barker's "linux-yocto CVEs
in need of triage" request, reworked according to his review of v2 [1].

Main changes since v2:

- Dropped the CVE-2023-4010 (imon) patch. The identification rested on
  inferring the reporter's intent from a screenshot, which the review
  rejected. The CVE record names a function that does not exist in the
  kernel (usb_giveback_urb()); I have reported that defect to the
  assigning CNA and left the CVE untriaged here.

- Moved the four entries that used "upstream-wontfix" (CVE-2019-14899,
  CVE-2021-3714, CVE-2021-3864, CVE-2022-4543) to "unpatched". None has
  an upstream kernel-community wontfix statement; the WONTFIX and
  deferred positions are distribution ones. "unpatched" keeps them
  visible in reports.

- CVE-2022-1247 now leads with the v7.1 removal of net/rose and keeps
  the v6.17 refcount commits, which are what cover the 6.18 kernel on
  master. Upstream has since assigned those two commits CVE-2025-39826
  and CVE-2025-39827, so the identification no longer rests on reading
  the diff alone.

- CVE-2023-3397: corrected the claim that only one fix was proposed and
  withdrawn; further fixes were posted in 2026 but none is merged, and
  syzbot still reproduces the txEnd()/lmLogClose() unmount race.

- CVE-2023-6240: dropped the Marvell/s390 aside and an unrelated commit
  reference flagged in review.

CVE-2022-0400 and CVE-2023-6238 are unchanged since v2.

AI assistance is disclosed with the AI-Generated trailer on each patch.

Summary of the nine verdicts:

  fixed-version   CVE-2022-1247   6.17, rose_neigh refcount conversion
  disputed        CVE-2022-0400   never substantiated, closed by three vendors
  unpatched       CVE-2019-14899  weak host model, config-only mitigation
                  CVE-2021-3714   inherent to KSM deduplication
                  CVE-2021-3864   two mitigation attempts, neither merged
                  CVE-2022-4543   KASLR not a boundary against local attackers
                  CVE-2023-3397   JFS txEnd UAF, no fix merged
                  CVE-2023-6238   NVMe fix applied then reverted
                  CVE-2023-6240   RSA timing oracle, fixed only in RHEL

Once these are settled I can prepare the wrynose and scarthgap backports.

[1] https://lore.kernel.org/openembedded-core/8bf8e31c06972ab4bfed61083d8d8c57e6c48d9e.camel@pbarker.dev/

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

Junjie Cao (9):
  cve-exclusions: set status for CVE-2019-14899
  cve-exclusions: set status for CVE-2021-3714
  cve-exclusions: set status for CVE-2021-3864
  cve-exclusions: set status for CVE-2022-0400
  cve-exclusions: set status for CVE-2022-1247
  cve-exclusions: set status for CVE-2022-4543
  cve-exclusions: set status for CVE-2023-3397
  cve-exclusions: set status for CVE-2023-6238
  cve-exclusions: set status for CVE-2023-6240

 meta/recipes-kernel/linux/cve-exclusion.inc | 67 +++++++++++++++++++++
 1 file changed, 67 insertions(+)

-- 
2.43.0

[OE-core][PATCH v3 1/9] cve-exclusions: set status for CVE-2019-14899

[Junjie Cao]

A network-adjacent attacker can send packets addressed to a host's VPN
tunnel address over the physical interface. Because Linux uses the weak
host model by default, the host replies, which lets the attacker infer
the tunnel address, confirm active connections and eventually inject
into the tunneled TCP stream.

No upstream kernel fix exists. The disclosure notes that reverse path
filtering is not a complete solution because the attack also works over
IPv6, which has no rp_filter; the mitigation that shipped was a firewall
rule added to wg-quick(8) in userspace:

  https://www.openwall.com/lists/oss-security/2019/12/05/1
  https://lore.kernel.org/all/20191205191318.GA44156@zx2c4.com/

Distribution trackers record the same state: Ubuntu has it deferred
since 2019-12-13, Debian does not track it against the kernel, and Red
Hat scopes it to openvpn:

  https://ubuntu.com/security/CVE-2019-14899
  https://security-tracker.debian.org/tracker/CVE-2019-14899

Record it unpatched so it stays visible rather than excluded.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3:
- use "unpatched" instead of "upstream-wontfix": there is no upstream
  statement, only distribution and disclosure sources

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index d27d764..5ed4a00 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -192,3 +192,10 @@ CVE_STATUS[CVE-2025-68195] = "fixed-version: Fixed from 6.18"
 # Fix https://git.kernel.org/stable/c/b4b64fda4d30a83a7f00e92a0c8a1d47699609f3
 # Backport https://git.kernel.org/stable/c/75c5d9bce072abbbc09b701a49869ac23c34a906
 CVE_STATUS[CVE-2025-71145] = "cpe-stable-backport: Fixed from v6.18.3"
+
+# Consequence of the default weak host model, not a specific defect;
+# mitigation is firewall configuration only (rp_filter for IPv4, a
+# strong host model rule such as wg-quick(8)'s, which also covers IPv6).
+# https://ubuntu.com/security/CVE-2019-14899
+CVE_STATUS[CVE-2019-14899] = "unpatched: consequence of the default weak \
+host model, no upstream kernel fix, mitigated by firewall configuration"
-- 
2.43.0

[OE-core][PATCH v3 2/9] cve-exclusions: set status for CVE-2021-3714

[Junjie Cao]

KSM merges identical anonymous pages across processes. An attacker who
can place chosen page-sized content in a victim's memory can detect the
merge through the timing of the resulting copy-on-write fault, and so
leak memory contents.

There is no upstream fix; removing the side channel means removing
deduplication. Distribution trackers describe it the same way - Debian
marks src:linux unfixed with "Inherent design limitation, can be avoided
by not using KSM", Red Hat closed its bug WONTFIX, and Ubuntu records no
upstream fix as of 2024-06-17:

  https://security-tracker.debian.org/tracker/CVE-2021-3714
  https://bugzilla.redhat.com/show_bug.cgi?id=1931327
  https://ubuntu.com/security/CVE-2021-3714

Exposure requires two runtime opt-ins: ksmd must be started by the
administrator (ksm_run defaults to KSM_RUN_STOP in mm/ksm.c) and memory
is only eligible when a process asks with madvise(MADV_MERGEABLE) or
prctl(PR_SET_MEMORY_MERGE). CONFIG_KSM=y is set in yocto-kernel-cache
(bsp/intel-x86 and the paravirt_kvm fragments), so this is not a
configuration exclusion.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3:
- use "unpatched" instead of "upstream-wontfix": the WONTFIX is a
  distribution position, not an upstream one

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index 5ed4a00..af3576d 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -199,3 +199,10 @@ CVE_STATUS[CVE-2025-71145] = "cpe-stable-backport: Fixed from v6.18.3"
 # https://ubuntu.com/security/CVE-2019-14899
 CVE_STATUS[CVE-2019-14899] = "unpatched: consequence of the default weak \
 host model, no upstream kernel fix, mitigated by firewall configuration"
+
+# Timing side channel inherent to KSM page deduplication. Reachable only
+# when ksmd is started (/sys/kernel/mm/ksm/run defaults to 0) and the
+# workload opts in via MADV_MERGEABLE or prctl(PR_SET_MEMORY_MERGE).
+# https://security-tracker.debian.org/tracker/CVE-2021-3714
+CVE_STATUS[CVE-2021-3714] = "unpatched: timing side channel inherent to \
+KSM page deduplication, only reachable when KSM is enabled and opted into"
-- 
2.43.0

[OE-core][PATCH v3 3/9] cve-exclusions: set status for CVE-2021-3864

[Junjie Cao]

begin_new_exec() resets dumpability to owner-dumpable whenever the real
and effective ids match at exec time. A binary exec'd by a setuid
program that has already called setuid(0) therefore becomes dumpable as
root, and with a relative core_pattern plus an attacker-controlled
working directory the resulting core file can be dropped into a
privileged directory such as /etc/logrotate.d.

Full report with proof of concept:

  https://www.openwall.com/lists/oss-security/2021/10/20/2

Two fixes were proposed and neither was merged. Waiman Long's patch was
judged an ineffective mitigation by Eric W. Biederman and the discussion
went quiet in early 2022; Wander Lairson Costa's RFC v2 received design
feedback and no v3 followed:

  https://lore.kernel.org/all/20211221021744.864115-1-longman@redhat.com/
  https://lore.kernel.org/all/20211228170910.623156-1-wander@redhat.com/

The flagged logic is unchanged: fs/exec.c still selects
TASK_DUMPABLE_OWNER in that case, and fs/coredump.c only applies the
suid-safe restriction when dumpable is TASK_DUMPABLE_ROOT, so the
dumpable==1 case this CVE describes is not covered. Images that set an
absolute path, a pipe or a socket core_pattern are not exploitable.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3:
- use "unpatched" instead of "upstream-wontfix"; a NAK of one
  mitigation is not an upstream wontfix of the issue
- drop the "NAKed" wording: the discussion went quiet, it was not
  formally rejected

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index af3576d..ba8e467 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -206,3 +206,11 @@ host model, no upstream kernel fix, mitigated by firewall configuration"
 # https://security-tracker.debian.org/tracker/CVE-2021-3714
 CVE_STATUS[CVE-2021-3714] = "unpatched: timing side channel inherent to \
 KSM page deduplication, only reachable when KSM is enabled and opted into"
+
+# Two mitigation attempts, neither merged; the fs/exec.c logic is
+# unchanged. An absolute, piped or socket kernel.core_pattern (for
+# example systemd-coredump) prevents exploitation.
+# https://www.openwall.com/lists/oss-security/2021/10/20/2
+# https://ubuntu.com/security/CVE-2021-3864
+CVE_STATUS[CVE-2021-3864] = "unpatched: no accepted mainline fix, \
+exploitation requires a relative kernel.core_pattern"
-- 
2.43.0

[OE-core][PATCH v3 4/9] cve-exclusions: set status for CVE-2022-0400

[Junjie Cao]

The CVE describes an out-of-bounds read in the SMC protocol stack, but
no vulnerable code was ever identified. The MITRE record lists the
affected version as "Not Known" and references only two Red Hat
bugzillas, the originating one of which was never made public.

The public bugzilla is closed as NOTABUG, with the statement "There was
no shipped kernel version that was seen affected by this problem":

  https://bugzilla.redhat.com/show_bug.cgi?id=2044575
  https://access.redhat.com/security/cve/CVE-2022-0400

SUSE reached the same conclusion independently, closing bsc#1195329 as
RESOLVED / INVALID:

  https://www.suse.com/security/cve/CVE-2022-0400.html

So did Debian, which marks it unimportant with the note "non issue, no
security impact":

  https://security-tracker.debian.org/tracker/CVE-2022-0400

There is no commit in mainline referencing this CVE. The net/smc
out-of-bounds fixes that landed in v5.18 (b1871fd48efc, 0558226cebee)
are in local, privileged paths and are not linked to this CVE by any
tracker.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3: no functional change since v2

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index ba8e467..be74672 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -214,3 +214,10 @@ KSM page deduplication, only reachable when KSM is enabled and opted into"
 # https://ubuntu.com/security/CVE-2021-3864
 CVE_STATUS[CVE-2021-3864] = "unpatched: no accepted mainline fix, \
 exploitation requires a relative kernel.core_pattern"
+
+# Never substantiated: no affected version, reproducer or commit was ever
+# identified. Closed NOTABUG by Red Hat, INVALID by SUSE (bsc#1195329) and
+# "non issue, no security impact" by Debian.
+# https://bugzilla.redhat.com/show_bug.cgi?id=2044575
+CVE_STATUS[CVE-2022-0400] = "disputed: the reported net/smc out-of-bounds read \
+was never substantiated and was closed as not-a-bug by Red Hat, SUSE and Debian"
-- 
2.43.0

[OE-core][PATCH v3 5/9] cve-exclusions: set status for CVE-2022-1247

[Junjie Cao]

The CVE describes a race between rose_connect() and the code that frees
a rose_neigh once its count and use fields reach zero.

net/rose, and rose_connect() with it, was removed entirely in v7.1:

  https://git.kernel.org/linus/dd8d4bc28ad7252610d8e79c1313a2d1e3499a51
  ("net: remove ax25 and amateur radio (hamradio) subsystem", v7.1)

The linux-yocto kernel on master is 6.18, which still carries net/rose.
There the race is closed by Takamitsu Iwai's August 2025 refcount
conversion, which converts the 'use' field to refcount_t and removes the
unlocked rose->neighbour->use++ in rose_connect() that the CVE describes:

  https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
  ("net: rose: convert 'use' field to refcount_t", v6.17)
  https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
  ("net: rose: include node references in rose_neigh refcount", v6.17)

Both are in v6.17 and were backported to 6.1.y, 6.6.y, 6.12.y and 6.16.y
in the 2025-09-02 stable round. Upstream assigned these two commits their
own identifiers, CVE-2025-39826 and CVE-2025-39827 (both fixed in
v6.17-rc4), so the identification does not rest on this reading of the
diff alone. The Red Hat record for CVE-2022-1247 still shows it open and
lists no fix.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3:
- lead with the v7.1 removal of net/rose per review; keep the v6.17
  commits, which are what covers the 6.18 kernel on master
- cite the upstream CVE-2025-39826 / CVE-2025-39827 assignments for
  the two fixing commits instead of relying on the diff match alone

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index be74672..b08eaa1 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -221,3 +221,11 @@ exploitation requires a relative kernel.core_pattern"
 # https://bugzilla.redhat.com/show_bug.cgi?id=2044575
 CVE_STATUS[CVE-2022-0400] = "disputed: the reported net/smc out-of-bounds read \
 was never substantiated and was closed as not-a-bug by Red Hat, SUSE and Debian"
+
+# net/rose and rose_connect() were removed entirely in v7.1 (dd8d4bc28ad7).
+# The 6.18 kernel on master still carries net/rose; there the race is
+# closed by the v6.17 refcount conversion, which upstream tracks as
+# CVE-2025-39826 / CVE-2025-39827.
+# Fix https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
+# Fix https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
+CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
-- 
2.43.0

[OE-core][PATCH v3 6/9] cve-exclusions: set status for CVE-2022-4543

[Junjie Cao]

KPTI clones the kernel entry text into the user page tables at its
KASLR-slid address and, on CPUs with PGE, sets the global bit on those
PTEs. The mapping survives the CR3 write on kernel exit, and a local
attacker can time prefetch instructions across the kernel range to
recover the KASLR base in well under a second.

Disclosure and write-up:

  https://www.openwall.com/lists/oss-security/2022/12/16/3
  https://www.willsroot.io/2022/12/entrybleed.html

The disclosure states that after discussion with security@kernel.org and
linux-distros "a fix for this is currently not available", and none has
appeared since; arch/x86/mm/pti.c still clones the entry text and sets
_PAGE_GLOBAL on the cloned PTEs. This is an unfixed issue, not a stated
wontfix - Debian notes "Ignored upstream and KASLR is not expected to be
resistant to local attacks", Ubuntu has it deferred since 2023-01-10:

  https://security-tracker.debian.org/tracker/CVE-2022-4543
  https://ubuntu.com/security/CVE-2022-4543

97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area", v6.2) randomizes
the separate cpu_entry_area; it predates this disclosure and does not
change the offset of entry_SYSCALL_64 from the KASLR base.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3:
- use "unpatched" instead of "upstream-wontfix": the security-team
  discussion produced no clear wontfix decision

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index b08eaa1..a909aef 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -229,3 +229,11 @@ was never substantiated and was closed as not-a-bug by Red Hat, SUSE and Debian"
 # Fix https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
 # Fix https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
 CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
+
+# "EntryBleed": KPTI maps the entry text into the user page tables with
+# the global bit set, leaking the KASLR base by prefetch timing. Discussed
+# with the kernel security team; no fix, KASLR is not treated as a boundary
+# against local attackers. Distinct from CVE-2023-3640 (cpu_entry_area).
+# https://www.willsroot.io/2022/12/entrybleed.html
+CVE_STATUS[CVE-2022-4543] = "unpatched: no upstream fix, KASLR is not \
+treated as a defence against local attackers"
-- 
2.43.0

[OE-core][PATCH v3 7/9] cve-exclusions: set status for CVE-2023-3397

[Junjie Cao]

txEnd() in fs/jfs/jfs_txnmgr.c reads the log pointer from the superblock
info, drops TXN_LOCK and then takes log->gclock, while lmLogClose() can
free that log during umount.

No fix has been merged. The 2023 proposal was withdrawn by its author
("I think my fix method is not a good solution"), and the 2026 proposals
for the same unmount race are unreviewed:

  https://lore.kernel.org/all/20230515095956.17898-1-zyytlz.wz@163.com/
  https://lore.kernel.org/all/20260505123330.2822833-1-tristmd@gmail.com/
  https://lore.kernel.org/all/20260603171620.2532527-1-jie.wang@intel.com/

The txEnd() sequence is unchanged in linux-next 20260727, and the
use-after-free was reported again in June 2026 against 7.0-rc1, with the
free stack in lmLogClose() via jfs_umount(); syzbot still lists it open:

  https://lore.kernel.org/all/6a3eedfa.fd822575.2d6b21.e180@mx.google.com/
  https://syzkaller.appspot.com/bug?extid=ea7ed3bb2f444cb4dfeb

CONFIG_JFS_FS=n in both ktypes/standard and ktypes/preempt-rt in
yocto-kernel-cache, and no fragment enables it.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3:
- correct the claim that only one fix was proposed and withdrawn:
  further fixes were posted in 2026 but none is merged
- add the syzbot dashboard and the June 2026 report as evidence the
  race is still live in mainline

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index a909aef..c4a9dea 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -237,3 +237,10 @@ CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
 # https://www.willsroot.io/2022/12/entrybleed.html
 CVE_STATUS[CVE-2022-4543] = "unpatched: no upstream fix, KASLR is not \
 treated as a defence against local attackers"
+
+# JFS txEnd()/lmLogClose() use-after-free on unmount. No fix merged: the
+# 2023 proposal was withdrawn, the 2026 proposals are unreviewed, and the
+# racy code is unchanged; syzbot still reproduces it.
+# https://syzkaller.appspot.com/bug?extid=ea7ed3bb2f444cb4dfeb
+CVE_STATUS[CVE-2023-3397] = "unpatched: no upstream fix merged, the \
+affected fs/jfs txEnd()/lmLogClose() unmount race is unchanged"
-- 
2.43.0

[OE-core][PATCH v3 8/9] cve-exclusions: set status for CVE-2023-6238

[Junjie Cao]

NVME_IOCTL_IO_CMD and the io_uring passthrough path accept a
metadata length from userspace without checking it against the number of
blocks and the namespace metadata size that the device uses to size the
transfer, so the device can DMA past the end of the buffer.

Kanchan Joshi posted a stopgap removing unprivileged passthrough,
reviewed by Christoph Hellwig and applied for nvme-6.6:

  https://lore.kernel.org/linux-nvme/20231016060519.231880-1-joshi.k@samsung.com/

It was then backed out. Keith Busch wrote "I believe this large change
is a bit too late for 6.6 ... It's backed out now", to which Christoph
Hellwig replied "We leave an exploitable hole in, so I don't think
waiting any longer is an option". No replacement has been merged: the
commits the patch would have reverted are all still present, and
nvme_map_user_request() still passes the user-supplied metadata length
straight to blk_rq_integrity_map_user() with no cross-check.

The exposure was introduced by
855b7717f44b ("nvme: fine-granular CAP_SYS_ADMIN for nvme io commands")
in v6.2, so branches carrying older kernels are not affected. Debian
reached the same conclusion independently, marking the older suites
"Vulnerable code not present":

  https://security-tracker.debian.org/tracker/CVE-2023-6238

Red Hat rates it Low because the device node is root-only by default:

  https://access.redhat.com/security/cve/CVE-2023-6238

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3: no functional change since v2

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index c4a9dea..35e0a66 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -244,3 +244,11 @@ treated as a defence against local attackers"
 # https://syzkaller.appspot.com/bug?extid=ea7ed3bb2f444cb4dfeb
 CVE_STATUS[CVE-2023-3397] = "unpatched: no upstream fix merged, the \
 affected fs/jfs txEnd()/lmLogClose() unmount race is unchanged"
+
+# The user metadata length is not checked against the length the device
+# derives from the command. The fix was applied to nvme-6.6 and then backed
+# out; nothing has landed since. Kernels before v6.2 predate unprivileged
+# passthrough (855b7717f44b) and are not affected.
+# https://lore.kernel.org/linux-nvme/20231016060519.231880-1-joshi.k@samsung.com/
+CVE_STATUS[CVE-2023-6238] = "unpatched: the proposed fix was applied to \
+nvme-6.6 and then reverted, no upstream fix has landed since"
-- 
2.43.0

[OE-core][PATCH v3 9/9] cve-exclusions: set status for CVE-2023-6240

[Junjie Cao]

"Marvin" is Hubert Kario's Bleichenbacher-style timing oracle research:

  https://people.redhat.com/~hkario/marvin/

The affected code is the generic software RSA PKCS#1 v1.5 unpadding in
crypto/rsa-pkcs1pad.c. pkcs1pad_decrypt_complete() has three
secret-dependent early exits (leading zero byte, block type, minimum
padding length) and a loop whose trip count depends on the position of
the separator, so the time taken reveals padding validity. There is no
constant-time unpadding or implicit-rejection fallback in the tree.

Red Hat classifies it CWE-203 and has shipped fixes only in RHEL errata
(RHSA-2024:2758, RHSA-2024:3618 and others); the bugzilla is still NEW.
Ubuntu records it unfixed upstream as of 2024-08-24 and Debian lists
src:linux vulnerable in all suites:

  https://access.redhat.com/security/cve/CVE-2023-6240
  https://ubuntu.com/security/CVE-2023-6240
  https://security-tracker.debian.org/tracker/CVE-2023-6240

Practical exposure is narrow: kernel PKCS#1 v1.5 use is dominated by
signature verification rather than decryption, and an attacker needs a
service driving KEYCTL_PKEY_DECRYPT with a long-lived key. The leaky
primitive is nevertheless reachable.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v3:
- drop the Marvell/s390 aside and the unrelated e8829ef1f73f paragraph
  flagged in review as LLM confusion artifacts

v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index 35e0a66..637f8b6 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -252,3 +252,10 @@ affected fs/jfs txEnd()/lmLogClose() unmount race is unchanged"
 # https://lore.kernel.org/linux-nvme/20231016060519.231880-1-joshi.k@samsung.com/
 CVE_STATUS[CVE-2023-6238] = "unpatched: the proposed fix was applied to \
 nvme-6.6 and then reverted, no upstream fix has landed since"
+
+# "Marvin": the PKCS#1 v1.5 unpadding in crypto/rsa-pkcs1pad.c branches on
+# secret-derived data, leaking padding validity by timing. Still present in
+# mainline; fixed only in RHEL errata.
+# https://people.redhat.com/~hkario/marvin/
+CVE_STATUS[CVE-2023-6240] = "unpatched: Bleichenbacher-style timing oracle in \
+crypto/rsa-pkcs1pad.c is still present in mainline, fixed only downstream in RHEL"
-- 
2.43.0