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

[Paolo Abeni <pabeni@redhat.com>]

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.

For the networking bits:

Acked-by: Paolo Abeni <pabeni@redhat.com>