On Wed, Mar 06, 2024 at 09:47:36AM +0800, GONG, Ruiqi wrote: > > > On 2024/03/05 18:10, Kees Cook wrote: > > Hi, > > > > Repeating the commit logs for patch 4 here: > > > > 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. > > > > In order to isolate user-controllable sized allocations from system > > allocations, introduce kmem_buckets_create(), which behaves like > > kmem_cache_create(). (The next patch will introduce kmem_buckets_alloc(), > > which behaves like kmem_cache_alloc().) > > So can I say the vision here would be to make all the kernel interfaces > that handles user space input to use separated caches? Which looks like > creating a "grey zone" in the middle of kernel space (trusted) and user > space (untrusted) memory. I've also thought that maybe hardening on the > "border" could be more efficient and targeted than a mitigation that > affects globally, e.g. CONFIG_RANDOM_KMALLOC_CACHES. I think it ends up having a similar effect, yes. The more copies that move to memdup_user(), the more coverage is created. The main point is to just not share caches between different kinds of allocations. The most abused version of this is the userspace size-controllable allocations, which this targets. The existing caches (which could still be used for type confusion attacks when the sizes are sufficiently similar) have a good chance of being mitigated by CONFIG_RANDOM_KMALLOC_CACHES already, so this proposed change is just complementary, IMO. -Kees -- Kees Cook
