Kernel isolates skb data allocations against UAF heap sprays
Kees Cook’s kmem_buckets series, capped by a Pedro Falcato networking change, gives socket-buffer payloads their own slab caches when slab buckets are enabled.
Linux kernel developers have posted a series that moves socket buffer data allocations into dedicated slab buckets, shutting down a common heap-spray path used after use-after-free bugs.
SKB data areas come from kmalloc and can be sized with substantial userspace control, especially via netlink. That makes them a practical way to overwrite a freed object that landed in the same general kmalloc cache, a technique shown in public exploits against bugs such as CVE-2023-4207. Randomized kmalloc caches already raise the bar probabilistically. The new work uses the kmem_buckets API so that, with slab buckets enabled, those allocations sit in their own non-merged caches instead of sharing the global pools.
Pedro Falcato wrote the networking change. Kees Cook handled the slab side: keeping memory-cgroup charged allocations (common for AF_UNIX) inside the isolated set, falling back to ordinary kmalloc only for rare needs such as GFP_DMA, matching bucket alignment to the kmalloc caches they mirror so DMA and debug configurations stay consistent, and adding teardown plus KUnit tests for the buckets API.
The series also restores memcg charging for System V message-queue objects when slab buckets are built out. An earlier conversion relied on SLAB_ACCOUNT on bucket caches that do not exist in that configuration, so those allocations stopped being charged to the sender’s cgroup. Harry Yoo called that a stable-worthy fix and argued the buckets abstraction is still too tightly tied to kmalloc fallbacks, preferring a clearer compatibility layer or making buckets mandatory. Cook floated dropping the compile-time option. Paolo Abeni had already acked the networking piece, and Cook asked for the full series to land through the slab tree.