CVE-2026-98231: xfrm: serialize state GC with device state flush
In the Linux kernel, the following vulnerability has been resolved:
xfrm: serialize state GC with device state flush
The deferred-device pass in xfrmdevstateflush() finds states under xfrmstatedevgclock, but drops the lock before calling xfrmdevstatefree() because the driver callback may sleep. The device GC list does not hold an xfrmstate 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 xfrmstatedevgclock read x->xso.dev xfrmstategcdestroy(x) xfrmdevstatefree(x) xfrmstatefree(x) continue xfrmdevstatefree(x)
Both paths can invoke the driver callback and drop the device reference. CPU 0 can also access the xfrmstate after CPU 1 has freed it.
KASAN reported:
BUG: KASAN: slab-use-after-free in xfrmdevstatefree+0x24c/0x2a0 Read of size 8 at addr ffff88810bbaa960 by task poc/102
Call Trace: xfrmdevstatefree+0x24c/0x2a0 xfrmdevstateflush+0x353/0x400 xfrmdevevent+0x26d/0x3a0 notifiercallchain+0xc0/0x280 devnotifyflags+0x169/0x250 netifchangeflags+0xe7/0x160 devchangeflags+0x96/0x220 devinetioctl+0x7f4/0x1880
Allocated by task 87: xfrmstatealloc+0x1e/0x5c0 xfrmaddsa+0xe7f/0x5820 xfrmuserrcvmsg+0x4f3/0x940
Freed by task 57: kmemcachefree+0xcb/0x3d0 xfrmstategctask+0x4a8/0x650 processonework+0x63a/0x1070
Serialize xfrmstate destruction against the deferred-device pass with a mutex. Keep xfrmstatedevgclock limited to list operations and retain the existing callback and device-reference release ordering.
Affected Software
Event History
Frequently Asked Questions
What conditions are needed to trigger this race?
The race involves XFRM device state flushing occurring concurrently with the XFRM state garbage-collection worker. It is associated with the deferred-device pass in xfrm_dev_state_flush() and can be reached through device events such as network-interface flag changes.
What is the observed impact?
Concurrent cleanup can cause both paths to invoke the driver callback and release the device reference for the same state. One path may then access an xfrm_state after the other has freed it, resulting in a slab use-after-free reported by KASAN.
How can I identify a potentially affected system?
Look for KASAN reports identifying a slab use-after-free in xfrm_dev_state_free(), with call paths involving xfrm_dev_state_flush(), xfrm_dev_event(), and network device flag-change handling. The provided data does not identify affected kernel versions.