CVE-2026-98231
xfrm: serialize state GC with device state flush
No known exploitation. EPSS puts it in the 9th percentile. Fixed versions are out.
What to do
Find your product and version, then upgrade to the build on the right.
- LinuxAffected: ≥ d5f53edd43daf3e6e1633a49c561387f8f99e13f, < 937108dc0258d6ac69926b00bc53598c98986ee1Upgrade to: 937108dc0258d6ac69926b00bc53598c98986ee1Affected: ≥ 07b87f9eea0c30675084d50c82532d20168da009, < 39e41af3653ee45c985190dd97426f318918d201Upgrade to: 39e41af3653ee45c985190dd97426f318918d201Affected: ≥ 07b87f9eea0c30675084d50c82532d20168da009, < 75fc4561772e2f9811abf39ed10443e6f4a4bc6cUpgrade to: 75fc4561772e2f9811abf39ed10443e6f4a4bc6cAffected: ≥ 07b87f9eea0c30675084d50c82532d20168da009, < 84e378395494963b1e581cf223a7cbeec8c0e2d6Upgrade to: 84e378395494963b1e581cf223a7cbeec8c0e2d6 + 4 more branchesStated by: CVE record
Versions as the sources state them. Full version matrix after sign-in
What it is
From the CVE record
In the Linux kernel, the following vulnerability has been resolved: xfrm: serialize state GC with device state flush The deferred-device pass in xfrm_dev_state_flush() finds states under xfrm_state_dev_gc_lock, but drops the lock before calling xfrm_dev_state_free() because the driver callback may sleep. The device GC list does not hold an xfrm_state reference, so the state GC worker can destroy the same state concurrently. The race can proceed as follows: CPU 0 CPU 1 find x on the device GC list drop xfrm_state_dev_gc_lock read x->xso.dev xfrm_state_gc_destroy(x) xfrm_dev_state_free(x) xfrm_state_free(x) continue xfrm_dev_state_free(x) Both paths can invoke the driver callback and drop the device reference. CPU 0 can also access the xfrm_state after CPU 1 has freed it. KASAN reported: BUG: KASAN: slab-use-after-free in xfrm_dev_state_free+0x24c/0x2a0 Read of size 8 at addr ffff88810bbaa960 by task poc/102 Call Trace: xfrm_dev_state_free+0x24c/0x2a0 xfrm_dev_state_flush+0x353/0x400 xfrm_dev_event+0x26d/0x3a0 notifier_call_chain+0xc0/0x280 __dev_notify_flags+0x169/0x250 netif_change_flags+0xe7/0x160 dev_change_flags+0x96/0x220 devinet_ioctl+0x7f4/0x1880 Allocated by task 87: xfrm_state_alloc+0x1e/0x5c0 xfrm_add_sa+0xe7f/0x5820 xfrm_user_rcv_msg+0x4f3/0x940 Freed by task 57: kmem_cache_free+0xcb/0x3d0 xfrm_state_gc_task+0x4a8/0x650 process_one_work+0x63a/0x1070 Serialize xfrm_state destruction against the deferred-device pass with a mutex. Keep xfrm_state_dev_gc_lock limited to list operations and retain the existing callback and device-reference release ordering.
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.2% chance of exploitation activity in the next 30 days, which ranks it in the 9th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
2 events over 0 days, from the signal feeds we watch.
- Publishedrecord updated
Affected products
Sources
References in the record
- git.kernel.org/stable/c/39e41af3653ee45c985190dd97426f318918d201
- git.kernel.org/stable/c/75fc4561772e2f9811abf39ed10443e6f4a4bc6c
- git.kernel.org/stable/c/84e378395494963b1e581cf223a7cbeec8c0e2d6
And 2 more references. See all after sign-in
In the news
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Linux, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI