[OE-core][PATCH v2 00/10] cve-exclusion: triage ten kernel CVEs lacking upstream fix data

[OE-core][PATCH v2 00/10] cve-exclusion: triage ten kernel CVEs lacking upstream fix data

[Junjie Cao]

This is v2 of the triage of the CVEs from Paul Barker's "linux-yocto CVEs
in need of triage" request [1], reworked according to his review [2]:
one patch per CVE, primary sources cited in every commit message, and
the three CVEs which have no upstream fix recorded as "unpatched" rather
than left out.

CVE-2023-3640 is not included; Adhitya is handling that one.

Summary of the ten verdicts:

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

Every commit referenced above was verified to exist and to be contained in
the stated release using git tag --contains against mainline history at
linux-next 20260727.

Two points for reviewer attention:

- CVE-2023-4010 (patch 8) is the one identification that rests on
  inference rather than an authoritative statement: the fixing commit
  carries no CVE reference. The reasoning is spelled out in the commit
  message; "disputed" would also be defensible and I am happy to respin
  that patch if preferred.

- CVE-2022-1247 (patch 5) is fixed in v6.17, but no distribution tracker
  has connected the fix to the CVE yet. If the conclusion looks right it
  would be worth reporting back to Ubuntu, Debian and Red Hat.

The AI-Generated trailer on each patch covers source research and the
drafting of the commit messages. Every commit hash, release attribution
and quotation was verified against mainline git history and the cited
sources before submission, and I take responsibility for the
conclusions.

Once these are settled I am happy to prepare the wrynose and scarthgap
backports.

[1]: https://lore.kernel.org/all/4ac849a706feb16688020d5bcc3e74aececd63cf.camel@pbarker.dev/
[2]: https://lore.kernel.org/openembedded-core/95aae562c0b8862ac687a63e8003143044519d6e.camel@pbarker.dev/

changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

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

Junjie Cao (10):
  cve-exclusion: set status for CVE-2019-14899
  cve-exclusion: set status for CVE-2021-3714
  cve-exclusion: set status for CVE-2021-3864
  cve-exclusion: set status for CVE-2022-0400
  cve-exclusion: set status for CVE-2022-1247
  cve-exclusion: set status for CVE-2022-4543
  cve-exclusion: set status for CVE-2023-3397
  cve-exclusion: set status for CVE-2023-4010
  cve-exclusion: set status for CVE-2023-6238
  cve-exclusion: 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 v2 01/10] cve-exclusion: 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 kernel fix exists. The original disclosure states that reverse path
filtering is not a solution because the attack also works over IPv6,
which has no rp_filter at all:

  https://www.openwall.com/lists/oss-security/2019/12/05/1

Kernel-level mitigations were discussed on netdev and the WireGuard list
in December 2019 but nothing was merged; the mitigation that shipped was
a firewall rule added to wg-quick(8) in userspace:

  https://lore.kernel.org/all/20191205191318.GA44156@zx2c4.com/

Ubuntu has the issue deferred for every release since 2019-12-13 and
records "No current fix from upstream":

  https://ubuntu.com/security/CVE-2019-14899

Debian does not track it against the kernel source package at all, and
Red Hat scopes it to openvpn rather than the kernel:

  https://security-tracker.debian.org/tracker/CVE-2019-14899
  https://access.redhat.com/security/cve/CVE-2019-14899

The NVD entry carries an unversioned linux_kernel CPE, so no fixed
version can ever match it.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

v1: https://lore.kernel.org/openembedded-core/20260802143444.1178575-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 d27d7644..aaba26fe 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 configuration only: rp_filter for IPv4, or a strong host
+# model rule such as the one wg-quick(8) installs, which also covers IPv6.
+# https://www.openwall.com/lists/oss-security/2019/12/05/1
+CVE_STATUS[CVE-2019-14899] = "upstream-wontfix: consequence of the default weak \
+host model, no kernel fix exists or is planned, mitigated by firewall configuration"
-- 
2.43.0

[OE-core][PATCH v2 02/10] cve-exclusion: 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 remotely.

This cannot be fixed without removing deduplication, and the affected
projects have said so explicitly. Red Hat closed the issue WONTFIX:

  https://bugzilla.redhat.com/show_bug.cgi?id=1931327

Debian marks src:linux unfixed with the note "Inherent design
limitation, can be avoided by not using KSM":

  https://security-tracker.debian.org/tracker/CVE-2021-3714

Ubuntu records "there is no upstream fix available as of 2024-06-17" and
lists disabling KSM as the only mitigation:

  https://ubuntu.com/security/CVE-2021-3714

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

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

v1: https://lore.kernel.org/openembedded-core/20260802143444.1178575-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 aaba26fe..9012d328 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://www.openwall.com/lists/oss-security/2019/12/05/1
 CVE_STATUS[CVE-2019-14899] = "upstream-wontfix: consequence of the default weak \
 host model, no kernel fix exists or is planned, mitigated by firewall configuration"
+
+# Inherent to KSM deduplication, closed WONTFIX by Red Hat. Exposure needs
+# ksmd started at runtime (/sys/kernel/mm/ksm/run defaults to 0) and the
+# workload to opt in via MADV_MERGEABLE or prctl(PR_SET_MEMORY_MERGE).
+# https://bugzilla.redhat.com/show_bug.cgi?id=1931327
+CVE_STATUS[CVE-2021-3714] = "upstream-wontfix: inherent design limitation of \
+KSM page deduplication, closed WONTFIX by Red Hat, no upstream fix planned"
-- 
2.43.0

[OE-core][PATCH v2 03/10] cve-exclusion: 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
NAKed by Eric W. Biederman as an ineffective mitigation:

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

Wander Lairson Costa's RFC v2 received design feedback and no v3 ever
followed:

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

The flagged logic is unchanged today: fs/exec.c still selects
TASK_DUMPABLE_OWNER in that case, and fs/coredump.c only rejects
relative core paths when dumpable is 2, so the dumpable==1 case this CVE
describes is not covered.

Ubuntu records "no fix upstream as of 2022-01-27" and defers it for all
releases; Debian lists src:linux as unfixed:

  https://ubuntu.com/security/CVE-2021-3864
  https://security-tracker.debian.org/tracker/CVE-2021-3864

Red Hat rates RHEL 8 and later "Not affected" purely because their
default core_pattern does not write relative to the current directory:

  https://access.redhat.com/security/cve/CVE-2021-3864

Images that set an absolute path, a pipe or a socket core_pattern (for
example systemd-coredump) are not exploitable for the same reason.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

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

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

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index 9012d328..d7ae3b03 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -206,3 +206,9 @@ host model, no kernel fix exists or is planned, mitigated by firewall configurat
 # https://bugzilla.redhat.com/show_bug.cgi?id=1931327
 CVE_STATUS[CVE-2021-3714] = "upstream-wontfix: inherent design limitation of \
 KSM page deduplication, closed WONTFIX by Red Hat, no upstream fix planned"
+
+# Two fix attempts, neither merged; the fs/exec.c logic is unchanged.
+# An absolute, piped or socket kernel.core_pattern prevents exploitation.
+# https://www.openwall.com/lists/oss-security/2021/10/20/2
+CVE_STATUS[CVE-2021-3864] = "upstream-wontfix: no accepted mainline fix after \
+several attempts, exploitation requires a relative kernel.core_pattern"
-- 
2.43.0

[OE-core][PATCH v2 04/10] cve-exclusion: 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>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

v1: https://lore.kernel.org/openembedded-core/20260802143444.1178575-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 d7ae3b03..0ae3a0d6 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -212,3 +212,10 @@ KSM page deduplication, closed WONTFIX by Red Hat, no upstream fix planned"
 # https://www.openwall.com/lists/oss-security/2021/10/20/2
 CVE_STATUS[CVE-2021-3864] = "upstream-wontfix: no accepted mainline fix after \
 several attempts, 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 v2 05/10] cve-exclusion: 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.

Takamitsu Iwai's August 2025 series converts that field to a proper
reference count and removes the unlocked increment in rose_connect()
which is exactly the operation 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)

The first commit message states the premise of the CVE almost verbatim:
"The 'use' field in struct rose_neigh is used as a reference counter but
lacks atomicity. This can lead to race conditions where a rose_neigh
structure is freed while still being referenced by other code paths",
and its diff deletes the "rose->neighbour->use++;" statement from
rose_connect(). The second merges the separate count and use counters,
which is the other half of the condition described by the CVE, and
closes a syzbot-reported slab-use-after-free.

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.

Kernels from v7.1 onwards are unaffected by construction, since the AX.25
and hamradio subsystems were removed:

  https://git.kernel.org/linus/dd8d4bc28ad7252610d8e79c1313a2d1e3499a51

The commits predate the association of this CVE with
any fix, so no tracker links them yet - Ubuntu, Debian and Red Hat all
still show the CVE as open. The identification above is based on the
commit contents matching the CVE description; the two 2022 rose patches
from Duoming Zhou that Ubuntu's tracker references fix different rose
bugs and are not the fix for this issue.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

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

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

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index 0ae3a0d6..7547cdfd 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -219,3 +219,9 @@ several attempts, 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"
+
+# Fix https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
+# Fix https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
+# Also in 6.1.150, 6.6.104, 6.12.y and 6.16.5 via the 2025-09-02 stable round.
+# The rose/hamradio subsystem was removed entirely in v7.1 (dd8d4bc28ad7).
+CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
-- 
2.43.0

[OE-core][PATCH v2 06/10] cve-exclusion: 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 therefore 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 technical 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 still
sets _PAGE_GLOBAL on the cloned PTEs as of v7.2, and no commit in
mainline references the issue.

Debian marks it unimportant with the note "Ignored upstream and KASLR is
not expected to be resistant to local attacks":

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

Ubuntu has it deferred since 2023-01-10 with "unfixed upstream", and
Red Hat lists current RHEL as Affected with no mitigation available:

  https://ubuntu.com/security/CVE-2022-4543
  https://access.redhat.com/security/cve/CVE-2022-4543

97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area", v6.2) randomizes
the CPU entry area, which is CVE-2023-3640. It predates this disclosure
and does not address it - the offset of entry_SYSCALL_64 from the KASLR
base is unchanged by that commit.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

v1: https://lore.kernel.org/openembedded-core/20260802143444.1178575-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 7547cdfd..3517318e 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -225,3 +225,10 @@ was never substantiated and was closed as not-a-bug by Red Hat, SUSE and Debian"
 # Also in 6.1.150, 6.6.104, 6.12.y and 6.16.5 via the 2025-09-02 stable round.
 # The rose/hamradio subsystem was removed entirely in v7.1 (dd8d4bc28ad7).
 CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
+
+# "EntryBleed": KPTI maps __entry_text into the user page tables with the
+# global bit set, leaking the KASLR base by prefetch timing. Intel only.
+# Not CVE-2023-3640, which is the separate cpu_entry_area (fixed in v6.2).
+# https://www.willsroot.io/2022/12/entrybleed.html
+CVE_STATUS[CVE-2022-4543] = "upstream-wontfix: no fix planned, KASLR is not \
+considered a defence against local attackers"
-- 
2.43.0

[OE-core][PATCH v2 07/10] cve-exclusion: 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.

The subsystem in the public CVE data is misleading: the "slub"
association comes from the KASAN slab report, but the affected code is
JFS. Red Hat's own title for the issue is "slab-use-after-free write in
txend due to race condition".

A fix adding a new mutex was posted, reviewed, and then withdrawn by its
author, who wrote "I think my fix method is not a good solution":

  https://lore.kernel.org/all/20230515095956.17898-1-zyytlz.wz@163.com/

No other fix has been posted, and the sequence in txEnd() is unchanged
in mainline as of linux-next 20260727. syzkaller was still reporting
"KASAN: slab-use-after-free Write in txEnd" in June 2026.

Ubuntu records "unfixed upstream as of 2023-09-01"; Debian lists
src:linux as vulnerable in every suite:

  https://ubuntu.com/security/CVE-2023-3397
  https://security-tracker.debian.org/tracker/CVE-2023-3397

CONFIG_JFS_FS=n in both ktypes/standard/standard.cfg and
ktypes/preempt-rt/preempt-rt.cfg in yocto-kernel-cache, and no fragment
there enables it; the only other occurrence is CONFIG_JFS_SECURITY in
the selinux feature, which has no effect without JFS_FS.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

v1: https://lore.kernel.org/openembedded-core/20260802143444.1178575-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 3517318e..827a487e 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -232,3 +232,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] = "upstream-wontfix: no fix planned, KASLR is not \
 considered a defence against local attackers"
+
+# JFS txEnd()/lmLogClose() use-after-free, not slub as the CVE data says.
+# The only proposed fix was withdrawn by its author; the racy code is
+# unchanged and syzbot still reproduces it as of June 2026.
+# https://lore.kernel.org/all/20230515095956.17898-1-zyytlz.wz@163.com/
+CVE_STATUS[CVE-2023-3397] = "unpatched: no upstream fix, the only proposed \
+patch was withdrawn by its author and the affected fs/jfs code is unchanged"
-- 
2.43.0

[OE-core][PATCH v2 08/10] cve-exclusion: set status for CVE-2023-4010

[Junjie Cao]

The CVE text attributes a system lockup to usb_giveback_urb() in the USB
HCD framework. That function does not exist in the kernel; the closest
name is usb_giveback_urb_bh(). Ubuntu's security team noted the same
discrepancy when triaging the issue.

The reporter's proof of concept identifies the actual driver. Its
output shows the imon driver repeatedly printing errors and consuming
CPU:

  https://github.com/wanrenmi/a-usb-kernel-bug

usb_rx_callback_intf0() and usb_rx_callback_intf1() in
drivers/media/rc/imon.c resubmitted the RX URB after logging an error,
so a device returning -EPROTO caused an unbounded warning loop. That is
fixed by:

  https://git.kernel.org/linus/eecd203ada43a4693ce6fdd3a58ae10c7819252c
  ("media: imon: make send_packet() more robust", v6.18)

whose commit message describes the same mechanism: "usb_rx_callback_intf0()
resubmits urb after printk(), and resubmitted urb causes
usb_rx_callback_intf0() to again get -EPROTO error. This results in
printk() flooding (RCU stalls)". The fix returns early for those error
codes instead of resubmitting.

The impact is lower than the CVE suggests. It needs physical access to
attach a malicious device, and Ubuntu's triage concluded "There is no
system lockup happening", only unthrottled logging:

  https://ubuntu.com/security/CVE-2023-4010

Ubuntu's tracker data reaches the same conclusion about which driver is
at fault: it records "break-fix: 21677cfc562a -" for this CVE, and
21677cfc562a is "V4L/DVB: ir-core: add imon driver", the commit that
introduced the driver. Their note explains the choice: "The imon driver
has been issuing those warnings since its inception, so using that as
the break commit."

The tie to the fixing commit is an inference: eecd203ada43 carries no
CVE reference or Fixes tag, so no tracker links the two. It rests on the
reported function not existing, Ubuntu and the reporter's PoC both
pointing at imon, and the mechanism the commit fixes matching the
report.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

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

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

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index 827a487e..0647586f 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -239,3 +239,8 @@ considered a defence against local attackers"
 # https://lore.kernel.org/all/20230515095956.17898-1-zyytlz.wz@163.com/
 CVE_STATUS[CVE-2023-3397] = "unpatched: no upstream fix, the only proposed \
 patch was withdrawn by its author and the affected fs/jfs code is unchanged"
+
+# Fix https://git.kernel.org/linus/eecd203ada43a4693ce6fdd3a58ae10c7819252c
+# The CVE names usb_giveback_urb(), which does not exist; the reporter's PoC
+# and Ubuntu's break-fix data both point at drivers/media/rc/imon.c.
+CVE_STATUS[CVE-2023-4010] = "fixed-version: Fixed from version 6.18"
-- 
2.43.0

[OE-core][PATCH v2 09/10] cve-exclusion: 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>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

v1: https://lore.kernel.org/openembedded-core/20260802143444.1178575-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 0647586f..506d3705 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -244,3 +244,11 @@ patch was withdrawn by its author and the affected fs/jfs code is unchanged"
 # The CVE names usb_giveback_urb(), which does not exist; the reporter's PoC
 # and Ubuntu's break-fix data both point at drivers/media/rc/imon.c.
 CVE_STATUS[CVE-2023-4010] = "fixed-version: Fixed from version 6.18"
+
+# 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 v2 10/10] cve-exclusion: set status for CVE-2023-6240

[Junjie Cao]

"Marvin" is Hubert Kario's Bleichenbacher-style timing oracle research,
not a Marvell or s390 issue as some data sets suggest:

  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 and no implicit-rejection fallback in the tree,
and no commit touching that file addresses decryption timing.

Red Hat classifies it CWE-203 and has shipped fixes only in RHEL
errata (RHSA-2024:2758 for 9.4, RHSA-2024:3618 for 8.10 and others);
the corresponding bugzilla is still NEW:

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

Ubuntu records "appears unfixed in upstream as of 2024.08.24" and
Debian lists src:linux as vulnerable in all suites:

  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.

e8829ef1f73f ("crypto: rsa - restrict plaintext/ciphertext values
more", v6.9) is unrelated: it enforces SP800-56B value restrictions and
is not a timing fix.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

v1: https://lore.kernel.org/openembedded-core/20260802143444.1178575-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 506d3705..4ac5e343 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -252,3 +252,10 @@ CVE_STATUS[CVE-2023-4010] = "fixed-version: Fixed from version 6.18"
 # 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. Not a Marvell or
+# s390 issue despite some data sets. Fixed only in RHEL downstream.
+# 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