Slab allocator hardening and cross-cache attacks

[Alexander Popov <alex.popov@linux.com>]

Hello!

I published the article "Kernel-hack-drill and a new approach to exploiting 
CVE-2024-50264 in the Linux kernel":
https://a13xp0p0v.github.io/2025/09/02/kernel-hack-drill-and-CVE-2024-50264.html

It's about exploiting CVE-2024-50264, a race condition in AF_VSOCK sockets that 
happens between the connect() system call and a POSIX signal, resulting in a 
use-after-free (UAF).

I chose Ubuntu Server 24.04 with OEM/HWE kernel as the target for my 
experiments. This kernel ships with kconfig options that neutralize naive heap 
spraying for UAF exploitation:
  - CONFIG_SLAB_BUCKETS=y, which creates a set of separate slab caches for 
allocations with user-controlled data;
  - CONFIG_RANDOM_KMALLOC_CACHES=y, which creates multiple copies of slab caches 
for normal kmalloc allocation and makes kmalloc randomly pick one based on code 
address.

I used my pet project kernel-hack-drill to learn how cross-cache attacks behave 
on the kernel with slab allocator hardening turned on. Kernel-hack-drill is an 
open-source project (published under GPL-3.0) that provides a testing 
environment for learning and experimenting with Linux kernel vulnerabilities, 
exploit primitives, and kernel hardening features:
https://github.com/a13xp0p0v/kernel-hack-drill

In kernel-hack-drill, I developed several prototypes that implement cross-cache 
and cross-allocator attacks. The article thoroughly describes the procedure I 
used to debug them.

After experimenting with kernel-hack-drill on Ubuntu Server 24.04, I found that 
CONFIG_RANDOM_KMALLOC_CACHES and CONFIG_SLAB_BUCKETS block naive UAF 
exploitation, yet they also make my cross-cache attacks completely stable. It 
looks like these allocator features give an attacker better control over the 
slab with vulnerable objects and reduce the noise from other objects. Would you 
agree?

It seems that, without a mitigation such as SLAB_VIRTUAL, the Linux kernel 
remains wide-open to cross-cache attacks.

Best regards,
Alexander