mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()
In the Linux kernel, the following vulnerability has been resolved: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy() After the commit in Fixes:, if a module that created a slab cache does not release all of its allocated objects before destroying the cache (at rmmod time), we might end up releasing the kmem_cache object without removing it from the slab_caches list thus corrupting the list as kmem_cache_destroy() ignores the return value from shutdown_cache(), which in turn never removes the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails to release all of the cache's slabs. This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y as after that ill release the system will immediately trip on list_add, or list_del, assertions similar to the one shown below as soon as another kmem_cache gets created, or destroyed: [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268) [ 1041.219165] ------------[ cut here ]------------ [ 1041.221517] kernel BUG at lib/list_debug.c:62! [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y, is to set
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.1.56, 6.5.6
- CVEs
- CVE-2023-52562
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 16:58 UTC · Revision 1
Source evidence
mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()
core-osv · Original sourcePublished 2 Mar 2024, 21:59 UTC
In the Linux kernel, the following vulnerability has been resolved: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy() After the commit in Fixes:, if a module that created a slab cache does not release all of its allocated objects before destroying the cache (at rmmod time), we might end up releasing the kmem_cache object without removing it from the slab_caches list thus corrupting the list as kmem_cache_destroy() ignores the return value from shutdown_cache(), which in turn never removes the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails to release all of the cache's slabs. This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y as after that ill release the system will immediately trip on list_add, or list_del, assertions similar to the one shown below as soon as another kmem_cache gets created, or destroyed: [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268) [ 1041.219165] ------------[ cut here ]------------ [ 1041.221517] kernel BUG at lib/list_debug.c:62! [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y, is to set
osv:CVE-2023-52562
Kernel
Fixed versions: 6.1.56, 6.5.6
Complete source record
{
"id": "14243db3c78acf4af3fcdd31258b0ba4ddab5a8eeb464319a8733b5e9bd37432",
"url": "https://osv.dev/vulnerability/CVE-2023-52562",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()",
"summary": "In the Linux kernel, the following vulnerability has been resolved: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy() After the commit in Fixes:, if a module that created a slab cache does not release all of its allocated objects before destroying the cache (at rmmod time), we might end up releasing the kmem_cache object without removing it from the slab_caches list thus corrupting the list as kmem_cache_destroy() ignores the return value from shutdown_cache(), which in turn never removes the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails to release all of the cache's slabs. This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y as after that ill release the system will immediately trip on list_add, or list_del, assertions similar to the one shown below as soon as another kmem_cache gets created, or destroyed: [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268) [ 1041.219165] ------------[ cut here ]------------ [ 1041.221517] kernel BUG at lib/list_debug.c:62! [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y, is to set",
"evidence": "osv:CVE-2023-52562",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.1.56",
"evidence": "/affected/1/ranges"
},
{
"value": "6.5.6",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2023-52562",
"aliases": [
"CVE-2023-52562"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "0495e337b7039191dfce6e03f5f830454b1fae6b"
},
{
"fixed": "a5569bb187521432f509b69dda7d29f78b2d38b0"
},
{
"fixed": "51988be187b041e5355245957b0b9751fa382e0d"
},
{
"fixed": "46a9ea6681907a3be6b6b0d43776dccc62cad6cf"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "5.19.8"
},
{
"fixed": "5.20"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "357321557920c805de2b14832002465c320eea4f"
}
]
}
],
"versions": [
"v5.19.17",
"v5.19.16",
"v5.19.15",
"v5.19.14",
"v5.19.13",
"v5.19.12",
"v5.19.11",
"v5.19.10",
"v5.19.9",
"v5.19.8"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2023-52562.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.1.56"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.5.6"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2023-52562.json"
}
}
],
"modified": "2026-10-28T02:30:38.150157771Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/46a9ea6681907a3be6b6b0d43776dccc62cad6cf",
"https://git.kernel.org/stable/c/51988be187b041e5355245957b0b9751fa382e0d",
"https://git.kernel.org/stable/c/a5569bb187521432f509b69dda7d29f78b2d38b0",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/52xxx/CVE-2023-52562.json",
"https://nvd.nist.gov/vuln/detail/CVE-2023-52562",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/52xxx/CVE-2023-52562.json"
}
},
"related_cves": [
{
"value": "CVE-2023-52562",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 505019,
"published_at": "2024-03-02T21:59:35.568+00:00"
}