linux-hardening - Re: [PATCH v5 4/6] mm/slab: Introduce kmem_buckets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87r0crut6v.fsf@linux.intel.com>
Date: Thu, 20 Jun 2024 15:48:24 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Kees Cook <kees@...nel.org>
Cc: Vlastimil Babka <vbabka@...e.cz>,  "GONG, Ruiqi"
 <gongruiqi@...weicloud.com>,  Christoph Lameter <cl@...ux.com>,  Pekka
 Enberg <penberg@...nel.org>,  David Rientjes <rientjes@...gle.com>,
  Joonsoo Kim <iamjoonsoo.kim@....com>,  jvoisin
 <julien.voisin@...tri.org>,  Andrew Morton <akpm@...ux-foundation.org>,
  Roman Gushchin <roman.gushchin@...ux.dev>,  Hyeonggon Yoo
 <42.hyeyoo@...il.com>,  Xiu Jianfeng <xiujianfeng@...wei.com>,  Suren
 Baghdasaryan <surenb@...gle.com>,  Kent Overstreet
 <kent.overstreet@...ux.dev>,  Jann Horn <jannh@...gle.com>,  Matteo Rizzo
 <matteorizzo@...gle.com>,  Thomas Graf <tgraf@...g.ch>,  Herbert Xu
 <herbert@...dor.apana.org.au>,  linux-kernel@...r.kernel.org,
  linux-mm@...ck.org,  linux-hardening@...r.kernel.org,
  netdev@...r.kernel.org
Subject: Re: [PATCH v5 4/6] mm/slab: Introduce kmem_buckets_create() and family

Kees Cook <kees@...nel.org> writes:

> Dedicated caches are available for fixed size allocations via
> kmem_cache_alloc(), but for dynamically sized allocations there is only
> the global kmalloc API's set of buckets available. This means it isn't
> possible to separate specific sets of dynamically sized allocations into
> a separate collection of caches.
>
> This leads to a use-after-free exploitation weakness in the Linux
> kernel since many heap memory spraying/grooming attacks depend on using
> userspace-controllable dynamically sized allocations to collide with
> fixed size allocations that end up in same cache.
>
> While CONFIG_RANDOM_KMALLOC_CACHES provides a probabilistic defense
> against these kinds of "type confusion" attacks, including for fixed
> same-size heap objects, we can create a complementary deterministic
> defense for dynamically sized allocations that are directly user
> controlled. Addressing these cases is limited in scope, so isolating these
> kinds of interfaces will not become an unbounded game of whack-a-mole. For
> example, many pass through memdup_user(), making isolation there very
> effective.

Isn't the attack still possible if the attacker can free the slab page
during the use-after-free period with enough memory pressure?

Someone else might grab the page that was in the bucket for another slab
and the type confusion could hurt again.

Or is there some other defense against that, other than
CONFIG_DEBUG_PAGEALLOC or full slab poisoning? And how expensive
does it get when any of those are enabled?

I remember reading some paper about a apple allocator trying similar
techniques and it tried very hard to never reuse memory (probably
not a good idea for Linux though)

I assume you thought about this, but it would be good to discuss such
limitations and interactions in the commit log.

-Andi