Slab allocator hardening and cross-cache attacks

Slab allocator hardening and cross-cache attacks

[Alexander Popov]

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

Re: Slab allocator hardening and cross-cache attacks

[Andrey Konovalov]

On Fri, Sep 5, 2025 at 10:11 PM Alexander Popov <alex.popov@linux.com> wrote:
>
> 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.

I'd second the notion that without SLAB_VIRTUAL, the attempts to
deterministically separate objects into different caches based on the
code location or the type (as also with the TYPED_KMALLOC_CACHES
series proposed by Marco [1]) aid exploitation more than prevent it.

Many kernel exploits nowadays rely on cross-cache attacks due to the
high portability of the post-cross-cache techniques for getting code
execution or escalating privileges. And with these object separation
features, the amount of unrelated-to-the-exploit allocation noise for
a specific slab cache gets significantly reduced or completely
removed. Which makes cross-cache attacks very stable.

The only negative effect these separation features have on cross-cache
attacks is that the attacker has to use the objects coming from the
affected slab cache (i.e. the cache from where the object affected by
the exploited vulnerability is allocated) for the slab shaping during
the cross-cache attack (filling up the slab, overflowing the partial
list, etc.). In practice, this is usually not a problem: the attacker
can often allocate as many objects as they want from the affected
cache (by using the same code path as the one required to allocate the
vulnerable object) and only trigger the vulnerability for one of them.

Having said that, I think it's still worth working on these separation
features with the hope that SLAB_VIRTUAL will at some point end up in
the kernel and be affordable enough to be enabled in production.

[1] https://lore.kernel.org/all/20250825154505.1558444-1-elver@google.com/