CVE-2026-93208 in Linux
Zusammenfassung
von VulDB • 24.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
kasan: Race Condition beim Cache-Sizing mit CPU-Hotplug beheben
kasan_quarantine_remove_cache() ruft zunächst per_cpu_remove_cache() auf allen online CPUs auf. Jeder Callback verschiebt Objekte, die zum Cache gehören, von cpu_quarantine in die shrink_qlist der jeweiligen CPU, wo sie später im Task-Kontext freigegeben werden können.
kmem_cache_destroy() ruft den Quarantäne-Entfernungspfad während des Halts von cpus_read_lock auf, kmem_cache_shrink() jedoch nicht. Letzteres kann daher mit dem Offline-Schalten der CPU wie folgt in einen Race Condition geraten:
kmem_cache_shrink() CPU-Hotplug ------------------- ----------- on_each_cpu() CPU1 verschiebt Objekte in die shrink_qlist von CPU1 on_each_cpu() kehrt zurück CPU1 geht offline kasan_cpu_offline() leert cpu_quarantine lässt shrink_qlist unberührt for_each_online_cpu() überspringt CPU1
Die auf der shrink_qlist von CPU1 verbleibenden Objekte werden nicht an den Slab-Allokator zurückgegeben. Dies kann verhindern, dass kmem_cache_shrink() Slabs freigibt, die andernfalls leer würden. Wenn CPU1 offline bleibt, überspringt ein späterer Aufruf von kmem_cache_destroy() ebenfalls diese Liste und meldet möglicherweise, dass der Cache noch Objekte enthält.
Es wurde ein intermittierendes Auftreten mit einem virtio-9p-Dateisystem beobachtet. Die Befehle mount und umount gaben beide 0 zurück, aber das Kernel-Log protokollierte Folgendes während des durch den Userspace ausgelösten Teardowns:
[ 2994.380134][ T111] BUG 9p-fcall-cache-1 (Tainted: G B ): Objects remaining on __kmem_cache_shutdown()
[ 2994.381140][ T111] Object 0xff11000004361118 @offset=4376
[ 2994.381607][ T111] Allocated in p9_fcall_init+0x201/0x400 age=19564 cpu=1 pid=104
[ 2994.382591][ T111] p9_fcall_init+0x201/0x400
[ 2994.382810][ T111] p9_tag_alloc+0x12f/0x700
[ 2994.382982][ T111] p9_client_prepare_req+0x102/0x3e0
[ 2994.383165][ T111] p9_client_rpc+0x1ab/0xa50
[ 2994.383334][ T111] p9_client_getattr_dotl+0xb0/0x1a0
[ 2994.383515][ T111] v9fs_vfs_getattr_dotl+0x115/0x360
[ 2994.383719][ T111] vfs_getattr_nosec+0x22c/0x3a0
[ 2994.383910][ T111] vfs_statx+0xd7/0x170
[ 2994.384062][ T111] vfs_fstatat+0x45/0x80
[ 2994.384215][ T111] __do_sys_newfstatat+0x84/0xe0
[ 2994.384386][ T111] do_syscall_64+0x115/0x6a0
[ 2994.384566][ T111] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2994.399720][ T111] WARNING: mm/slub.c:1244 at __kmem_cache_shutdown+0x363/0x500, CPU#0: busybox/111
[ 2994.405655][ T111] Call Trace:
[ 2994.406325][ T111] kmem_cache_destroy+0x73/0x1b0
[ 2994.406630][ T111] p9_client_destroy+0x271/0x3c0
[ 2994.407210][ T111] v9fs_session_close+0x3c/0x260
[ 2994.407409][ T111] v9fs_kill_super+0x48/0x90
[ 2994.407584][ T111] deactivate_locked_super+0xa3/0x160
[ 2994.407778][ T111] cleanup_mnt+0x1dd/0x3e0
Somit hinterließ ein erfolgreicher umount- Vorgang Objekte im 9p fcall-Cache und verhinderte, dass der Cache sauber zerstört wurde.
Die pro-CPU shrink_qlist-Speicherung existiert für jede mögliche CPU, und jede Liste wird durch ihr eigenes raw spinlock geschützt. Iterieren Sie über alle möglichen CPUs, damit auch eine Liste geleert wird, die vor dem Offline-Gang ihrer CPU befüllt wurde.
for_each_possible_cpu() kann mehr Arbeit verrichten als for_each_online_cpu(), aber diese Änderung betrifft nur CONFIG_KASAN_GENERIC-Kernel. Die zusätzliche Arbeit ist auf Cache-Sizing- und Cache-Zerstörungspfade beschränkt und hat keinen Einfluss auf den normalen Allokations-/Freigabe-Fastpath. Sie fügt einen durch ein raw-spinlock geschützten Scan der shrink-Liste jeder möglichen CPU hinzu. Diese Listen sind normalerweise leer; eine nicht-leere Liste wird durchlaufen, um Objekte zu entfernen, die zum gerade verkleinerten oder zerstörten Cache gehören.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.