[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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:

We should drop the discussion of mitigations here - none of them are
complete mitigations and there are more nuances.

> 
>   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"

I recommend slightly different wording. Include the triage date, drop
discussion of mitigation.

    # Triaged August 2026 - no upstream fix, Ubuntu fix deferred
    # https://ubuntu.com/security/CVE-2019-14899
    CVE_STATUS[CVE-2019-14899] = "unpatched: Consequence of the default weak host \
    model, no upstream fix"

Best regards,

-- 
Paul Barker

[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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.

We should drop this third paragraph - it's time consuming to validate.

> 
> 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"

I recommend we change the wording, add more links and include the triage
date:

    # Triaged August 2026 - no upstream fix, Debian says "Inherent design
    # limitation, can be avoided by not using KSM", Red Hat closed their bug as
    # WONTFIX.
    # 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
    CVE_STATUS[CVE-2021-3714] = "unpatched: Timing side channel inherent to Kernel \
    Same-page Merging (KSM) page deduplication"

Best regards,

-- 
Paul Barker

[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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.

This third paragraph is unnecessary detail.

> 
> 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"

Suggested wording, links, and include triage date:

    # Triaged August 2026 - Two fixes proposed upstream but neither was merged,
    # attempts to fix seem to have petered out. Unfixed in Debian/Ubuntu.
    # https://lore.kernel.org/all/20211221021744.864115-1-longman@redhat.com/
    # https://lore.kernel.org/all/20211228170910.623156-1-wander@redhat.com/
    # https://security-tracker.debian.org/tracker/CVE-2021-3864
    # https://ubuntu.com/security/CVE-2021-3864
    CVE_STATUS[CVE-2021-3864] = "unpatched: Proposed fixes were not merged upstream"

Best regards,

-- 
Paul Barker

[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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

The second sentence of the statement in the Red Hat CVE entry is "These
files are not built in our source code". The "no shipped kernel version
was affected" statement is specific to Red Hat's configuration, and
without further info it doesn't really help anyone.

Drop the reference to that statement and the second of the two links,
it's misleading as it's easy to read it as a universal statement instead
of a Red Hat specific statement. Keep the first link as the report being
closed NOTABUG is interesting.

> 
> SUSE reached the same conclusion independently, closing bsc#1195329 as
> RESOLVED / INVALID:
> 
>   https://www.suse.com/security/cve/CVE-2022-0400.html

Include a link to https://bugzilla.suse.com/show_bug.cgi?id=1195329.

> 
> So did Debian, which marks it unimportant with the note "non issue, no
> security impact":
> 
>   https://security-tracker.debian.org/tracker/CVE-2022-0400

I read "non issue..." in the context of "Vulnerable code not present".
So the relevant thing is that Debian doesn't build the affected code. As
above we should be careful as the way you've referenced this makes it
sound like a blanket statement that there was no security impact in any
configuration.

It's also worth mentioning that Debian links to Red Hat bug #2040604,
but that's not public.

> 
> 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.

I would drop the references to unrelated commits.

> 
> 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"

We should try to get Red Hat to release more info before we close this
as disputed.

Best regards,

-- 
Paul Barker

[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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.

We can simplify the explanation here. The issue reported in
CVE-2022-1247 was independently fixed in v6.17 via two commits, these
were assigned CVE-2025-39826 & CVE-2025-39827 by the Linux kernel CVE
assignment team. The race condition described in the original report for
CVE-2022-1247 [1] exactly matches what was fixed.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2066799

> 
> 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"

The comment and CVE_STATUS wording looks good to me. We don't need a
triage date on this one as we're effectively resolving it.

Best regards,

-- 
Paul Barker

[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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.

There's too much unnecessary detail here. Drop the mention of a commit
that doesn't fix the issue, you don't need to say "not a stated
wontfix", etc.

> 
> 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"

Suggested wording, links and include triage date:

    # Triaged August 2026 - "EntryBleed", discussed with the kernel security team
    # but no fix appears to have been published since then. Debian says "Ignored
    # upstream and KASLR is not expected to be resistant to local attacks", fix
    # deferred in Ubuntu.
    # https://www.openwall.com/lists/oss-security/2022/12/16/3
    # https://security-tracker.debian.org/tracker/CVE-2022-4543
    # https://ubuntu.com/security/CVE-2022-4543
    CVE_STATUS[CVE-2022-4543] = "unpatched: No fix has been proposed"

Best regards,

-- 
Paul Barker

[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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 proposed patches from this year are certainly for a similar slab
use-after-free race, but I can't be sure it's exactly the same. So
please re-word this.

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

Again, may be a similar use-after-free, validating that it is exactly
the same one is time consuming.

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

Yes, but users may enable this, so it's not relevant to the analysis.

> 
> 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"

Recommended wording, links and include triage date:

    # Triaged August 2026 - Originally proposed fix was withdrawn, similar
    # slab-use-after-free appears to have been re-found by syzkaller in 2026.
    # Unfixed in Debian, "needs evaluation" in Ubuntu.
    # https://lore.kernel.org/lkml/CAJedcCzmx02bfa22QezE8mu-iDsSdSy_oApT2ozCWO8O-8MJEQ@mail.gmail.com/
    # https://syzkaller.appspot.com/bug?extid=ea7ed3bb2f444cb4dfeb
    # https://security-tracker.debian.org/tracker/CVE-2023-3397
    # https://ubuntu.com/security/CVE-2023-3397
    CVE_STATUS[CVE-2023-3397] = "unpatched: Proposed fix was withdrawn"

Best regards,

-- 
Paul Barker

[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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

The explanation is confusing here as it misses what actually introduced
a vulnerability. NVME_IOCTL_IO_CMD has always passed through metadata
length without validation. Commit 855b7717f44b allowed less privileged
users to issue NVME_IOCTL_IO_CMD if they have write access to the nvme
device node.

We don't need to recount the story of the patch being applied to the
nvme tree then backed out. It never landed in mainline, that's what
matters.

> 
> 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"

Recommended wording, links and include triage date:

    # Triaged August 2026 - Issue was introducted by kernel commit 855b7717f44b
    # ("nvme: fine-granular CAP_SYS_ADMIN for nvme io commands") in Linux v6.2.
    # Linux 6.1 and earlier not affected. Unfixed in recent Debian/Ubuntu releases
    # which use affected kernels. There was a fix proposed, but it was not merged
    # to mainline.
    # https://security-tracker.debian.org/tracker/CVE-2023-6238
    # https://ubuntu.com/security/CVE-2023-6238
    # https://lore.kernel.org/linux-nvme/20231016060519.231880-1-joshi.k@samsung.com/
    CVE_STATUS[CVE-2023-6238] = "unpatched: Proposed fix was withdrawn"

Best regards,

-- 
Paul Barker

[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

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> "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.

I'd drop this paragraph. Validating its claims would be time consuming.

> 
> 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"

Recommended wording, links and include triage date:

    # Triaged August 2026 - "Marvin" attack, Red Hat reports this fixed but the
    # exact patch is unidentified (see RHSA-2024:2758, RHSA-2024:3618 & others).
    # Unfixed in Debian, "Needs evaluation" in Ubuntu.
    # https://people.redhat.com/~hkario/marvin/
    # https://access.redhat.com/security/cve/cve-2023-6240
    # https://security-tracker.debian.org/tracker/CVE-2023-6240
    # https://ubuntu.com/security/CVE-2023-6240
    CVE_STATUS[CVE-2023-6240] = "unpatched: Fixed in RHEL but patch not identified \
    publicly"

Best regards,

-- 
Paul Barker

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

[Paul Barker]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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.

Hi,

I have spent some time validating the status of all the issues and I
think we're nearly there. I've suggested changes to the commit messages,
comments and CVE_STATUS wordings, with those addressed I think 8/9 of
these will be ready to merge.

CVE-2022-0400 still bothers me. There was clearly something reported,
there's a non-public Red Hat bugzilla entry referenced by Debian [1]. It
looks like it was closed by Red Hat, SUSE and Debian as they don't build
the affected code, not because it was an invalid report. We should ask
Red Hat to release more details.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2040604

Best regards,

-- 
Paul Barker