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

[Paul Barker <paul@pbarker.dev>]

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