[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+fCnZdQDDwkcd153qexNDP-61VAbB4iAJrj02UVtoL8KN2Vjw@mail.gmail.com>
Date: Fri, 5 Sep 2025 23:18:32 +0200
From: Andrey Konovalov <andreyknvl@...il.com>
To: alex.popov@...ux.com
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, linux-hardening@...r.kernel.org,
kasan-dev <kasan-dev@...glegroups.com>, Kees Cook <keescook@...omium.org>,
Kees Cook <kees@...nel.org>, Jann Horn <jannh@...gle.com>, Marco Elver <elver@...gle.com>,
Matteo Rizzo <matteorizzo@...gle.com>, Florent Revest <revest@...gle.com>,
GONG Ruiqi <gongruiqi1@...wei.com>, Harry Yoo <harry.yoo@...cle.com>,
Peter Zijlstra <peterz@...radead.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Slab allocator hardening and cross-cache attacks
On Fri, Sep 5, 2025 at 10:11 PM Alexander Popov <alex.popov@...ux.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/
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
