On Thu, Jun 20, 2024 at 03:48:24PM -0700, Andi Kleen wrote: > Kees Cook <kees@xxxxxxxxxx> 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. Yup! It's in there; it's just after what you quoted above. Here it is: > > Memory allocation pinning[2] is still needed to plug the Use-After-Free > > cross-allocator weakness, but that is an existing and separate issue > > which is complementary to this improvement. Development continues for > > that feature via the SLAB_VIRTUAL[3] series (which could also provide > > guard pages -- another complementary improvement). > > [...] > > Link: https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html [2] > > Link: https://lore.kernel.org/lkml/20230915105933.495735-1-matteorizzo@xxxxxxxxxx/ [3] Let me know if you think this description needs to be improved... -Kees -- Kees Cook
