CVE-2024-36892

What it actually does

The SLUB allocator's slab_free() path zeroes objects when init_on_free is enabled but skips updating an external freepointer (under slub_debug=F and CONFIG_SLAB_FREELIST_HARDENED), causing check_object() to falsely report freepointer corruption on subsequent single-object frees.

Why it matters to the business

Kernel builds or hardened systems using init_on_free and SLUB debug flags may encounter spurious BUG reports or stability issues during normal memory allocation patterns, increasing operational noise and potential downtime in development or security-hardened deployments. No ransomware or known exploitation activity reduces immediate urgency.

How an attack unfolds

An attacker would trigger repeated single-object kmalloc/kfree operations on a system booted with init_on_free=1 and slub_debug=F; the kernel's internal consistency checks then incorrectly flag the zeroed external freepointer as corrupt, but the condition does not grant code execution or privilege escalation.

How to fix it

Update the Linux kernel to commit 56900355485f6e82114b18c812edd57fd7970dcb or later; distributions should backport the fix that preserves the freepointer during single frees when init_on_free is active.

How to confirm the fix worked

Confirm the patch is present by checking for the updated slab_free() logic that avoids zeroing external freepointers; reproduce with the original command-line flags and verify absence of the false-positive BUG message in dmesg.

Typical attack path

1. Boot kernel with init_on_free=1 and slub_debug=FU plus CONFIG_SLAB_FREELIST_HARDENED
2. Perform single (non-bulk) allocations and frees from user space or drivers
3. Trigger slab_free_hook() which zeroes the object but leaves the hardened freepointer untouched
4. do_slab_free() slow path invokes check_object() which decodes the zeroed pointer and logs "Freepointer corrupt"

How to detect it

Search kernel logs for the exact string "Freepointer corrupt" accompanied by a slab object offset and a zeroed fp value; correlate with boot parameters containing init_on_free and slub_debug=F.

• BUG kmalloc-rnd-.*: Freepointer corrupt
• Object .* fp=0x0000000000000000
• init_on_free=1 slub_debug=F

What your security team should do

• Apply the referenced upstream commit or distribution kernel update containing 56900355485f6e82114b18c812edd57fd7970dcb
• Review any custom kernel configs that combine init_on_free with slub_debug=F and disable the combination until patched
• Monitor kernel bug reports for similar freepointer messages as an indicator of incomplete backports