CVE-2026-93208: kasan: fix cache shrink race with CPU hotplug
In the Linux kernel, the following vulnerability has been resolved:
kasan: fix cache shrink race with CPU hotplug
kasanquarantineremovecache() first invokes percpuremovecache() on all online CPUs. Each callback moves objects belonging to the cache from cpuquarantine to the CPU's shrinkqlist, where they can later be freed from task context.
kmemcachedestroy() invokes the quarantine removal path while holding cpusreadlock(), but kmemcacheshrink() does not. The latter can therefore race with CPU offlining as follows:
kmemcacheshrink() CPU hotplug ------------------- ----------- oneachcpu() CPU1 moves objects to CPU1's shrinkqlist oneachcpu() returns CPU1 goes offline kasancpuoffline() drains cpuquarantine leaves shrinkqlist untouched foreachonlinecpu() skips CPU1
The objects left on CPU1's shrinkqlist are not returned to the slab allocator. This may prevent kmemcacheshrink() from releasing slabs that would otherwise become empty. If CPU1 remains offline, a later kmemcachedestroy() also skips the list and can report that the cache still contains objects.
An intermittent occurrence was observed with a virtio-9p filesystem. The mount and umount commands both returned 0, but the kernel logged the following during the userspace-triggered teardown:
[ 2994.380134][ T111] BUG 9p-fcall-cache-1 (Tainted: G B ): Objects remaining on kmemcacheshutdown() [ 2994.381140][ T111] Object 0xff11000004361118 @offset=4376 [ 2994.381607][ T111] Allocated in p9fcallinit+0x201/0x400 age=19564 cpu=1 pid=104 [ 2994.382591][ T111] p9fcallinit+0x201/0x400 [ 2994.382810][ T111] p9tagalloc+0x12f/0x700 [ 2994.382982][ T111] p9clientpreparereq+0x102/0x3e0 [ 2994.383165][ T111] p9clientrpc+0x1ab/0xa50 [ 2994.383334][ T111] p9clientgetattrdotl+0xb0/0x1a0 [ 2994.383515][ T111] v9fsvfsgetattrdotl+0x115/0x360 [ 2994.383719][ T111] vfsgetattrnosec+0x22c/0x3a0 [ 2994.383910][ T111] vfsstatx+0xd7/0x170 [ 2994.384062][ T111] vfsfstatat+0x45/0x80 [ 2994.384215][ T111] dosysnewfstatat+0x84/0xe0 [ 2994.384386][ T111] dosyscall64+0x115/0x6a0 [ 2994.384566][ T111] entrySYSCALL64afterhwframe+0x77/0x7f [ 2994.399720][ T111] WARNING: mm/slub.c:1244 at kmemcacheshutdown+0x363/0x500, CPU#0: busybox/111 [ 2994.405655][ T111] Call Trace: [ 2994.406325][ T111] kmemcachedestroy+0x73/0x1b0 [ 2994.406630][ T111] p9clientdestroy+0x271/0x3c0 [ 2994.407210][ T111] v9fssessionclose+0x3c/0x260 [ 2994.407409][ T111] v9fskillsuper+0x48/0x90 [ 2994.407584][ T111] deactivatelockedsuper+0xa3/0x160 [ 2994.407778][ T111] cleanupmnt+0x1dd/0x3e0
Thus, a successful umount left objects in the 9p fcall cache and prevented the cache from being destroyed cleanly.
Per-CPU shrinkqlist storage exists for every possible CPU, and each list is protected by its own raw spinlock. Iterate over possible CPUs so that a list populated before its CPU went offline is drained as well.
foreachpossiblecpu() can do more work than foreachonlinecpu(), but this change only affects CONFIGKASANGENERIC kernels. The extra work is limited to cache shrink and cache destruction paths and does not affect the normal allocation/free fast path. It adds one raw-spinlock-protected scan of each possible CPU's shrink list. These lists are normally empty; a non-empty list is traversed to remove objects belonging to the cache being shrunk or destroyed.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this race?
Systems using KASAN are affected when a cache shrink operation can run concurrently with CPU offlining. The reported intermittent occurrence involved a virtio-9p filesystem during mount and unmount activity.
What conditions are required for the issue to occur?
A kmem_cache_shrink() operation must move cache objects onto a CPU's shrink_qlist, and that CPU must then go offline before the objects are processed. Because the subsequent scan considers only online CPUs, the offline CPU's list can be skipped.
What is the operational impact?
Objects can remain on the offline CPU's shrink_qlist instead of being returned to the slab allocator, preventing slabs from being released when they otherwise could become empty. If the CPU remains offline, later cache destruction can also report that the cache still contains objects.
How can administrators recognize a possible occurrence?
A possible indicator is a cache-destruction report stating that a cache still contains objects, particularly after CPU offlining activity. The issue is described as intermittent.