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

[Andrey Konovalov]

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