| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2023-52562: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy() |
| |
| Description |
| =========== |
| |
| 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 slub_debug to poison the released objects and then just run |
| cat /proc/slabinfo after removing the module that leaks slab objects, |
| in which case the kernel will panic: |
| |
| [ 50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI |
| [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G B W OE 6.5.0 #15 |
| [ 50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 |
| [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0 |
| |
| This patch fixes this issue by properly checking shutdown_cache()'s |
| return value before taking the kmem_cache_release() branch. |
| |
| The Linux kernel CVE team has assigned CVE-2023-52562 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.0 with commit 0495e337b7039191dfce6e03f5f830454b1fae6b and fixed in 6.1.56 with commit a5569bb187521432f509b69dda7d29f78b2d38b0 |
| Issue introduced in 6.0 with commit 0495e337b7039191dfce6e03f5f830454b1fae6b and fixed in 6.5.6 with commit 51988be187b041e5355245957b0b9751fa382e0d |
| Issue introduced in 6.0 with commit 0495e337b7039191dfce6e03f5f830454b1fae6b and fixed in 6.6 with commit 46a9ea6681907a3be6b6b0d43776dccc62cad6cf |
| Issue introduced in 5.19.8 with commit 357321557920c805de2b14832002465c320eea4f |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2023-52562 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| mm/slab_common.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/a5569bb187521432f509b69dda7d29f78b2d38b0 |
| https://git.kernel.org/stable/c/51988be187b041e5355245957b0b9751fa382e0d |
| https://git.kernel.org/stable/c/46a9ea6681907a3be6b6b0d43776dccc62cad6cf |