CVE-2024-53065 - Duplicate kmem_cache Creation Warning in Linux kernel's mm/slab

In May 2024, security researchers and kernel maintainers found and patched a subtle but important bug in the Linux kernel memory allocator (mm/slab), identified as CVE-2024-53065. This advisory breaks down what happened, why you should care—even if you’re not a low-level coder—and why this matters for both kernel developers and security professionals.

At its core, this bug is about redundant memory structure creation. Let’s break that down

- The Linux kernel uses special caches (called kmem_cache) to manage small chunks of frequently used memory.
- For performance and hardware reasons, these caches are split up by size and per certain hardware alignment needs.
- Recent changes reduced the minimum alignment for the main memory allocator (kmalloc()) to 8 bytes on ARM64 CPUs—_unless_ a security feature called KASAN_HW_TAGS (a run-time memory checker) is enabled. If KASAN_HW_TAGS is on, the minimum alignment is set to 16 bytes.

Here’s where the bug pops up

When both these settings collide, two entries in the cache table (kmalloc_caches[*][8] and kmalloc_caches[*][16]) actually point to the same underlying cache, but code in kmem_buckets_create() tries to create both as if they’re distinct.
- Result: The kernel tries to create a cache object of the same name ("memdup_user-16", for example) twice on boot.

Effect: You’ll see kernel warnings and backtraces, e.g.

[    2.325108] ------------[ cut here ]------------
[    2.325135] kmem_cache of name 'memdup_user-16' already exists
[    2.325783] WARNING: CPU:  PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+xb8/x3b
...
[    2.404716] kmem_cache of name 'msg_msg-16' already exists
[    2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+xb8/x3b

- ### Direct consequences

- Boot-time kernel warnings: Normally harmless, but no warning in the kernel is ever truly “safe”.
- Potential for logic bugs: Duplicate cache creation _could_, in the worst case, mess up memory management, cause leaks, or trigger subtle logic errors under rare system loads.
- Security implications: While not a direct privilege escalation vector, such unexpected state can create a foundation for further memory manipulation exploits, especially on hardened systems (if a cache pointer is freed twice, etc.).

Timeline

- Commit introduced bug: b035f5a6d852 (mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible)
- Impacted kernel versions: Mainly 6.12-rc5 and experimental ARM64 builds with KASAN_HW_TAGS; may impact other configurations if defaults are changed.

Below is a simplified pseudocode of what was happening under the hood

/* (pseudo) code excerpt showing the cache aliasing issue */
int min_align = arch_slab_minalign(); // returns 8 or 16 depending on config

for (int i = ; i < NUM_KMALLOC_SIZES; i++) {
    size_t req_size = kmalloc_size_table[i];
    /* This produces two identical sizes if min_align changes */
    if (already_created_cache_for(req_size))
        continue;
    kmem_cache_create(name_for_size(req_size), req_size, min_align, ...);
}

But in reality, the function to check for existing cache didn't properly account for the aliasing caused by the changed min_align, so the same cache structure could be initialized multiple times with the same name, triggering kernel warnings.

Exploitability: Is This a Security Risk?

In practice:

There is no immediate direct privilege escalation or memory corruption, _by itself_.

- However: Any kernel bug that manipulates memory backend and issues warnings about allocator state should be patched. Unexpected double creation of internal kernel objects can be a foothold for attackers in kernel hardening, side-channel, or race condition exploits, particularly on systems where KASAN and memory debugging features are enabled.

In short

- On _unpatched kernels_, anyone able to force reboots under varied KASAN settings could try to leverage bad cache state as a local DoS or, as part of a chained exploit, try to escalate privileges.

How Was It Fixed?

The patch updated the creation process to avoid creating duplicate caches by properly tracking which cache sizes and alignments are already installed, even when the underlying minimum alignment changes under the hood.

From the commit message

+/* Only allocate one cache when multiple sizes alias */
+if (kmem_cache_already_exists(name))
+    continue;

Full fix available in the official Linux kernel source

- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac7e49c3fa9fca621f1fbf1b17d5996baaf5a19

References

- Linux Kernel Patch
- Commit introducing bug
- Arch Linux kernel bug report (example)
- KASAN Hardware Tagging

What Should You Do?

- Kernel maintainers: Cherry-pick the fix if maintaining custom ARM64, KASAN-enabled or recent 6.12 Linux kernels.
- Security teams: Watch for related warnings in your logs. If you see “kmem_cache of name 'xyz' already exists,” ensure you’re running a patched kernel.
- Regular Linux users: If you don’t compile your own kernels, just make sure your distribution is up to date.

Conclusion

CVE-2024-53065 is a classic tale of how low-level memory management assumptions can break when security features interact with architecture-specific tweaks—a “tiny warning” that could snowball into bigger problems. Thanks to the kernel devs who spotted and fixed it fast!

If you want to see the original patch and discussion, check the Linux kernel mailing list entry or the official commit page.

Timeline

Published on: 11/19/2024 18:15:26 UTC
Last modified on: 11/25/2024 21:04:38 UTC