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 <[email protected]> > AI-Generated: Uses Claude (claude-opus-5) > Signed-off-by: Junjie Cao <[email protected]> > --- > 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/[email protected]/ > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243535): https://lists.openembedded.org/g/openembedded-core/message/243535 Mute This Topic: https://lists.openembedded.org/mt/120714055/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
