Re: [PATCH v4 7/7] net: skb: isolate skb data area allocations into a separate bucket

[Kees Cook <kees@kernel.org>]

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 <pfalcato@suse.de>
> > 
> > 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 <kees@kernel.org>
> > Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> 
> 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 <pabeni@redhat.com>

Thanks!

-- 
Kees Cook