CVE-2026-98231

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.