CVE-2024-56566 - Linux Kernel SLUB List Corruption Bug and How It Was Fixed

A critical bug with the Linux kernel’s memory allocator (SLUB) could lead to memory list corruption, making Linux systems crash or behave unpredictably, especially under debugging settings. This vulnerability, tracked as CVE-2024-56566, has now been resolved—but for anyone running custom builds, odd debug settings, or those interested in kernel internals, understanding how it happens and how it was fixed is important.

This post explains the vulnerability, shows what went wrong in the SLUB code, and even offers a code snippet illustrating the patch. We will use simple language to keep it accessible.

TL;DR

- Component affected: mm/slub (SLUB memory allocator in Linux)

Trigger: Using slub_debug=UFPZ boot params

- Bug: Removing a slab (memory page) from internal lists after a debug-consistency failure corrupts the slab list, leading to kernel crashes

Fix: Mark and quarantine broken slabs so they’re not reused and don’t corrupt kernel memory

- Potential Impact: Local denial of service, possibly privilege escalation in very limited scenarios (if not mitigated by other kernel hardening).

What is SLUB and Why Does It Matter?

SLUB is the default memory allocator for the slab cache in the Linux kernel. It’s essential for efficiently allocating and freeing objects frequently used by the kernel itself, like network buffers, file cache, etc.

When debugging or diagnosing kernel bugs, users sometimes boot Linux with special flags, such as slub_debug=UFPZ, making SLUB check for subtle memory errors. But... running with debug options exposes some latent code paths, as this CVE demonstrates.

Here’s the timeline, simplified

1. Allocating with Checks: When allocating an object, SLUB verifies memory consistency. If a check fails (using alloc_consistency_checks()), SLUB marks *all* objects in that slab page as used, and removes the slab from the “partial” list.

Freeing Later: Later, when an object from the same slab is freed, SLUB calls remove_full().

3. Invalid List State: The slab is already off both the partial and full lists, so when remove_full() tries to update the list, it finds a poisoned pointer (LIST_POISON1), causing a bug and possibly crashing the kernel.

Error example from kernel log

list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100)
kernel BUG at lib/list_debug.c:56!
...
Call Trace:
 free_to_partial_list+x515/x5e
 xfs_iext_remove+x41a/xa10 [xfs]
...

In less technical terms:
A memory page was double-removed from SLUB’s internal lists, corrupting the linked lists SLUB maintains. Once corrupted, future operations can’t trust the memory data, and the kernel might crash or panic.

Exploiting CVE-2024-56566

- Who can exploit: A local attacker that can allocate and free objects from kernel slab caches (often any process, depending on the workload).
- What they could do: Force kernel crashes (denial of service). More sophisticated exploitation is possible, but hard, given most distros ship with kernel hardening and without slub_debug.
- When is it dangerous? Mostly on kernels booted with slub_debug. Most production systems do *not* enable this, but test/dev environments might. Kernel privilege escalation would require substantial additional vulnerabilities or a very weak configuration.

The Fix (in Code!)

Solution: Instead of allowing a “broken” slab to re-enter the allocator’s circulation (and possibly be freed again), the kernel now marks that slab as corrupted and isolates it; it never goes back into use.

Patch snippet (simplified for clarity)

// in mm/slub.c

// Mark slab as "metadata corrupted" using the 'frozen' bit (reused for debug)
if (unlikely(metadata_corruption_detected)) {
    set_slab_frozen(slab);
    // isolate from all slab lists
    list_del_init(&slab->list);
    // Never return this slab to use
}

Full fix: SLUB: Avoid list corruption when removing a slab from the full list

Check kernel version. Most major distributions backport this patch.

- Are you running with slub_debug=? (Check via cat /proc/cmdline)
- Review official CVE entry and Linux stable mailing list for more details.

References

- Mainline Linux Patch Commit
- CVE-2024-56566 at MITRE
- Red Hat Bugzilla entry
- LKML Patch Discussion

Production Servers: Not vulnerable unless explicitly running with debug options.

- For Kernel Developers/Debuggers: Always ensure the latest stable kernel when using debugging flags.
- For Security Teams: This CVE is not likely a “big” RCE, but a reminder about extra caution when enabling debug or diagnostic boot parameters.

Stay patched and check those kernel boot arguments!

If you use slub_debug, update your kernel *today*. If not, you’re pretty safe, but there’s always a good reason to keep those updates rolling.


(Exclusive: This post and code examples are written for educational purposes and simplified for clarity. For production fixes, always rely on official Linux distribution kernels and upstream patches.)

Timeline

Published on: 12/27/2024 15:15:15 UTC
Last modified on: 05/04/2025 09:58:31 UTC