On Sun, Sep 27, 2026 at 10:24:16AM +0200, Paolo Abeni wrote: > On 9/21/26 09:58, Kees Cook wrote: > > From: Pedro Falcato <[email protected]> > > > > SKB data area allocations (as done from alloc_skb()) use kmalloc(). > > These allocations can be variably sized and their contents can be more > > or less controlled from userspace, which makes them useful for attackers > > that want to overwrite a use-after-free'd object from the same kmalloc slab > > (which often just requires the sizes to roughly match into the same kmalloc > > bucket). [0] is an easy example of an exploit that uses netlink skb > > allocation to target another similarly-sized accidentally freed object. > > > > While other mitigations like CONFIG_RANDOM_KMALLOC_CACHES exist, these are > > probabilistic. Use the existing kmem buckets API to further isolate these > > allocations in a guaranteed fashion, when CONFIG_SLAB_BUCKETS=y. > > > > Ask for the accounted kmalloc type as well as the normal one. AF_UNIX > > sets sk_allocation to GFP_KERNEL_ACCOUNT, so without it every AF_UNIX > > skb data area would fall back to the general caches, and those are the > > ones most worth isolating. GFP_DMA is left to fall back, being passed to > > an skb allocator only by rare devices. > > > > Link: > > https://github.com/google/security-research/blob/master/pocs/linux/kernelctf/CVE-2023-4207_lts_cos_mitigation_2/docs/exploit.md > > [0] > > Reviewed-by: Kees Cook <[email protected]> > > Signed-off-by: Pedro Falcato <[email protected]> > > I would be curious to learn how about the memory usage delta. > However I see buckets are protected by their own kconfig, small > systems can unselect them.
Correct. But here's the delta for a 1 node NUMA with memcg, which is dominated by sysfs. 26 caches (13 normal and 13 memcg): sysfs, 26 caches 113,152 struct kmem_cache, 26 6,656 kmem_cache_node, 26 1,664 node_barn, 26 1,664 names, 26 1,248 the set itself, 2 rows × 14 pointers in kmalloc_buckets 224 per-CPU sheaf structs CPUSx x 832 > For the networking bits: > > Acked-by: Paolo Abeni <[email protected]> Thanks! -- Kees Cook
