UBUNTU-CVE-2026-93208: Medium severity ubuntu/linux-hwe-edge vulnerability

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.