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

[Paul Barker <paul@pbarker.dev>]

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