From: Jakub Kicinski <kuba@kernel.org>
To: Pedro Falcato <pfalcato@suse.de>
Cc: Vlastimil Babka <vbabka@kernel.org>, Harry Yoo <harry@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
linux-hardening@vger.kernel.org, linux-mm@kvack.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Hao Li <hao.li@linux.dev>, Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Simon Horman <horms@kernel.org>,
Jason Xing <kerneljasonxing@gmail.com>,
Kuniyuki Iwashima <kuniyu@google.com>
Subject: Re: [PATCH 2/2] net: skb: isolate skb data area allocations into a separate bucket
Date: Thu, 4 Jun 2026 18:52:22 -0700 [thread overview]
Message-ID: <20260604185222.794ea329@kernel.org> (raw)
In-Reply-To: <20260602183122.747759-3-pfalcato@suse.de>
On Tue, 2 Jun 2026 19:31:22 +0100 Pedro Falcato wrote:
> 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.
No idea on the merits but from networking point of view:
Acked-by: Jakub Kicinski <kuba@kernel.org>
next prev parent reply other threads:[~2026-06-05 1:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 18:31 [PATCH 0/2] net: isolate SKB data area allocations Pedro Falcato
2026-06-02 18:31 ` [PATCH 1/2] mm/slab: add a node-track-caller variant for kmem buckets allocation Pedro Falcato
2026-06-04 5:19 ` Harry Yoo
2026-06-04 19:12 ` Pedro Falcato
2026-06-05 11:59 ` Vlastimil Babka (SUSE)
2026-06-05 18:08 ` Kees Cook
2026-06-02 18:31 ` [PATCH 2/2] net: skb: isolate skb data area allocations into a separate bucket Pedro Falcato
2026-06-04 5:30 ` Harry Yoo
2026-06-04 19:12 ` Pedro Falcato
2026-06-05 5:45 ` Harry Yoo
2026-06-05 7:25 ` Eric Dumazet
2026-06-05 1:52 ` Jakub Kicinski [this message]
2026-06-05 18:09 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260604185222.794ea329@kernel.org \
--to=kuba@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=horms@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kuniyu@google.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pfalcato@suse.de \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.