{"id":28472,"date":"2026-09-25T00:31:31","date_gmt":"2026-09-24T16:31:31","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-93208"},"modified":"2026-09-25T00:31:31","modified_gmt":"2026-09-24T16:31:31","slug":"cve-2026-93208","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-93208","title":{"rendered":"CVE-2026-93208 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nkasan: fix cache shri"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>kasan: fix cache shrink race with CPU hotplug<\/p>\n<p>kasan_quarantine_remove_cache() first invokes per_cpu_remove_cache() on<br \/>\nall online CPUs.  Each callback moves objects belonging to the cache from<br \/>\ncpu_quarantine to the CPU&#8217;s shrink_qlist, where they can later be freed<br \/>\nfrom task context.<\/p>\n<p>kmem_cache_destroy() invokes the quarantine removal path while holding<br \/>\ncpus_read_lock(), but kmem_cache_shrink() does not.  The latter can<br \/>\ntherefore race with CPU offlining as follows:<\/p>\n<p>  kmem_cache_shrink()             CPU hotplug<br \/>\n  &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-             &#8212;&#8212;&#8212;&#8211;<br \/>\n  on_each_cpu()<br \/>\n    CPU1 moves objects to<br \/>\n    CPU1&#8217;s shrink_qlist<br \/>\n  on_each_cpu() returns<br \/>\n                                  CPU1 goes offline<br \/>\n                                  kasan_cpu_offline()<br \/>\n                                    drains cpu_quarantine<br \/>\n                                    leaves shrink_qlist untouched<br \/>\n  for_each_online_cpu()<br \/>\n    skips CPU1<\/p>\n<p>The objects left on CPU1&#8217;s shrink_qlist are not returned to the slab<br \/>\nallocator.  This may prevent kmem_cache_shrink() from releasing slabs that<br \/>\nwould otherwise become empty.  If CPU1 remains offline, a later<br \/>\nkmem_cache_destroy() also skips the list and can report that the cache<br \/>\nstill contains objects.<\/p>\n<p>An intermittent occurrence was observed with a virtio-9p filesystem.  The<br \/>\nmount and umount commands both returned 0, but the kernel logged the<br \/>\nfollowing during the userspace-triggered teardown:<\/p>\n<p>  [  2994.380134][  T111] BUG 9p-fcall-cache-1 (Tainted: G    B              ): Objects remaining on __kmem_cache_shutdown()<br \/>\n  [  2994.381140][  T111] Object 0xff11000004361118 @offset=4376<br \/>\n  [  2994.381607][  T111] Allocated in p9_fcall_init+0x201\/0x400 age=19564 cpu=1 pid=104<br \/>\n  [  2994.382591][  T111]  p9_fcall_init+0x201\/0x400<br \/>\n  [  2994.382810][  T111]  p9_tag_alloc+0x12f\/0x700<br \/>\n  [  2994.382982][  T111]  p9_client_prepare_req+0x102\/0x3e0<br \/>\n  [  2994.383165][  T111]  p9_client_rpc+0x1ab\/0xa50<br \/>\n  [  2994.383334][  T111]  p9_client_getattr_dotl+0xb0\/0x1a0<br \/>\n  [  2994.383515][  T111]  v9fs_vfs_getattr_dotl+0x115\/0x360<br \/>\n  [  2994.383719][  T111]  vfs_getattr_nosec+0x22c\/0x3a0<br \/>\n  [  2994.383910][  T111]  vfs_statx+0xd7\/0x170<br \/>\n  [  2994.384062][  T111]  vfs_fstatat+0x45\/0x80<br \/>\n  [  2994.384215][  T111]  __do_sys_newfstatat+0x84\/0xe0<br \/>\n  [  2994.384386][  T111]  do_syscall_64+0x115\/0x6a0<br \/>\n  [  2994.384566][  T111]  entry_SYSCALL_64_after_hwframe+0x77\/0x7f<br \/>\n  [  2994.399720][  T111] WARNING: mm\/slub.c:1244 at __kmem_cache_shutdown+0x363\/0x500, CPU#0: busybox\/111<br \/>\n  [  2994.405655][  T111] Call Trace:<br \/>\n  [  2994.406325][  T111]  kmem_cache_destroy+0x73\/0x1b0<br \/>\n  [  2994.406630][  T111]  p9_client_destroy+0x271\/0x3c0<br \/>\n  [  2994.407210][  T111]  v9fs_session_close+0x3c\/0x260<br \/>\n  [  2994.407409][  T111]  v9fs_kill_super+0x48\/0x90<br \/>\n  [  2994.407584][  T111]  deactivate_locked_super+0xa3\/0x160<br \/>\n  [  2994.407778][  T111]  cleanup_mnt+0x1dd\/0x3e0<\/p>\n<p>Thus, a successful umount left objects in the 9p fcall cache and prevented<br \/>\nthe cache from being destroyed cleanly.<\/p>\n<p>Per-CPU shrink_qlist storage exists for every possible CPU, and each list<br \/>\nis protected by its own raw spinlock.  Iterate over possible CPUs so that<br \/>\na list populated before its CPU went offline is drained as well.<\/p>\n<p>for_each_possible_cpu() can do more work than for_each_online_cpu(), but<br \/>\nthis change only affects CONFIG_KASAN_GENERIC kernels.  The extra work is<br \/>\nlimited to cache shrink and cache destruction paths and does not affect<br \/>\nthe normal allocation\/free fast path.  It adds one raw-spinlock-protected<br \/>\nscan of each possible CPU&#8217;s shrink list.  These lists are normally empty;<br \/>\na non-empty list is traversed to remove objects belonging to the cache<br \/>\nbeing shrunk or destroyed.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>kasan: fix cache shrink race with CPU hotplug<\/p>\n<p>kasan_quarantine_remove_cache() first invokes per_cpu_remove_cache() on<br \/>\nall online C<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-28472","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/28472","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=28472"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=28472"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=28472"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}