FKIE_CVE-2026-93208
Vulnerability from fkie_nvd - Published: 2026-09-24 16:17 - Updated: 2026-09-24 16:17
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
kasan: fix cache shrink race with CPU hotplug
kasan_quarantine_remove_cache() first invokes per_cpu_remove_cache() on
all online CPUs. Each callback moves objects belonging to the cache from
cpu_quarantine to the CPU's shrink_qlist, where they can later be freed
from task context.
kmem_cache_destroy() invokes the quarantine removal path while holding
cpus_read_lock(), but kmem_cache_shrink() does not. The latter can
therefore race with CPU offlining as follows:
kmem_cache_shrink() CPU hotplug
------------------- -----------
on_each_cpu()
CPU1 moves objects to
CPU1's shrink_qlist
on_each_cpu() returns
CPU1 goes offline
kasan_cpu_offline()
drains cpu_quarantine
leaves shrink_qlist untouched
for_each_online_cpu()
skips CPU1
The objects left on CPU1's shrink_qlist are not returned to the slab
allocator. This may prevent kmem_cache_shrink() from releasing slabs that
would otherwise become empty. If CPU1 remains offline, a later
kmem_cache_destroy() 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 __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
Thus, a successful umount left objects in the 9p fcall cache and prevented
the cache from being destroyed cleanly.
Per-CPU shrink_qlist 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.
for_each_possible_cpu() can do more work than for_each_online_cpu(), but
this change only affects CONFIG_KASAN_GENERIC 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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/kasan/quarantine.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "7cd164f0e1bab0f8dd125c92ed4f19bbd6b92a4a",
"status": "affected",
"version": "07d067e4f2ceb72b9f681995cc53828caaba9e6e",
"versionType": "git"
},
{
"lessThan": "709c3646545e0a1f99a5816384c633f6552c5a98",
"status": "affected",
"version": "07d067e4f2ceb72b9f681995cc53828caaba9e6e",
"versionType": "git"
},
{
"lessThan": "30e8cb8598aa41b1b9f8803081d2ae5e5369c0f3",
"status": "affected",
"version": "07d067e4f2ceb72b9f681995cc53828caaba9e6e",
"versionType": "git"
},
{
"lessThan": "3119d58e4ef8719d669911d38a53fc00086ac48b",
"status": "affected",
"version": "07d067e4f2ceb72b9f681995cc53828caaba9e6e",
"versionType": "git"
},
{
"lessThan": "8790303cbaac52a11dfed4aab261f8ea60682525",
"status": "affected",
"version": "07d067e4f2ceb72b9f681995cc53828caaba9e6e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/kasan/quarantine.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.19"
},
{
"lessThan": "5.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.157",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.109",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.50",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc1",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nkasan: fix cache shrink race with CPU hotplug\n\nkasan_quarantine_remove_cache() first invokes per_cpu_remove_cache() on\nall online CPUs. Each callback moves objects belonging to the cache from\ncpu_quarantine to the CPU\u0027s shrink_qlist, where they can later be freed\nfrom task context.\n\nkmem_cache_destroy() invokes the quarantine removal path while holding\ncpus_read_lock(), but kmem_cache_shrink() does not. The latter can\ntherefore race with CPU offlining as follows:\n\n kmem_cache_shrink() CPU hotplug\n ------------------- -----------\n on_each_cpu()\n CPU1 moves objects to\n CPU1\u0027s shrink_qlist\n on_each_cpu() returns\n CPU1 goes offline\n kasan_cpu_offline()\n drains cpu_quarantine\n leaves shrink_qlist untouched\n for_each_online_cpu()\n skips CPU1\n\nThe objects left on CPU1\u0027s shrink_qlist are not returned to the slab\nallocator. This may prevent kmem_cache_shrink() from releasing slabs that\nwould otherwise become empty. If CPU1 remains offline, a later\nkmem_cache_destroy() also skips the list and can report that the cache\nstill contains objects.\n\nAn intermittent occurrence was observed with a virtio-9p filesystem. The\nmount and umount commands both returned 0, but the kernel logged the\nfollowing during the userspace-triggered teardown:\n\n [ 2994.380134][ T111] BUG 9p-fcall-cache-1 (Tainted: G B ): Objects remaining on __kmem_cache_shutdown()\n [ 2994.381140][ T111] Object 0xff11000004361118 @offset=4376\n [ 2994.381607][ T111] Allocated in p9_fcall_init+0x201/0x400 age=19564 cpu=1 pid=104\n [ 2994.382591][ T111] p9_fcall_init+0x201/0x400\n [ 2994.382810][ T111] p9_tag_alloc+0x12f/0x700\n [ 2994.382982][ T111] p9_client_prepare_req+0x102/0x3e0\n [ 2994.383165][ T111] p9_client_rpc+0x1ab/0xa50\n [ 2994.383334][ T111] p9_client_getattr_dotl+0xb0/0x1a0\n [ 2994.383515][ T111] v9fs_vfs_getattr_dotl+0x115/0x360\n [ 2994.383719][ T111] vfs_getattr_nosec+0x22c/0x3a0\n [ 2994.383910][ T111] vfs_statx+0xd7/0x170\n [ 2994.384062][ T111] vfs_fstatat+0x45/0x80\n [ 2994.384215][ T111] __do_sys_newfstatat+0x84/0xe0\n [ 2994.384386][ T111] do_syscall_64+0x115/0x6a0\n [ 2994.384566][ T111] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n [ 2994.399720][ T111] WARNING: mm/slub.c:1244 at __kmem_cache_shutdown+0x363/0x500, CPU#0: busybox/111\n [ 2994.405655][ T111] Call Trace:\n [ 2994.406325][ T111] kmem_cache_destroy+0x73/0x1b0\n [ 2994.406630][ T111] p9_client_destroy+0x271/0x3c0\n [ 2994.407210][ T111] v9fs_session_close+0x3c/0x260\n [ 2994.407409][ T111] v9fs_kill_super+0x48/0x90\n [ 2994.407584][ T111] deactivate_locked_super+0xa3/0x160\n [ 2994.407778][ T111] cleanup_mnt+0x1dd/0x3e0\n\nThus, a successful umount left objects in the 9p fcall cache and prevented\nthe cache from being destroyed cleanly.\n\nPer-CPU shrink_qlist storage exists for every possible CPU, and each list\nis protected by its own raw spinlock. Iterate over possible CPUs so that\na list populated before its CPU went offline is drained as well.\n\nfor_each_possible_cpu() can do more work than for_each_online_cpu(), but\nthis change only affects CONFIG_KASAN_GENERIC kernels. The extra work is\nlimited to cache shrink and cache destruction paths and does not affect\nthe normal allocation/free fast path. It adds one raw-spinlock-protected\nscan of each possible CPU\u0027s shrink list. These lists are normally empty;\na non-empty list is traversed to remove objects belonging to the cache\nbeing shrunk or destroyed."
}
],
"id": "CVE-2026-93208",
"lastModified": "2026-09-24T16:17:15.497",
"metrics": {},
"published": "2026-09-24T16:17:15.497",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/30e8cb8598aa41b1b9f8803081d2ae5e5369c0f3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3119d58e4ef8719d669911d38a53fc00086ac48b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/709c3646545e0a1f99a5816384c633f6552c5a98"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7cd164f0e1bab0f8dd125c92ed4f19bbd6b92a4a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/8790303cbaac52a11dfed4aab261f8ea60682525"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…