All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org, Antonius <antonius@bluedragonsec.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Jason Xing" <kerneljasonxing@gmail.com>,
	"Kuniyuki Iwashima" <kuniyu@google.com>,
	"Michal Luczaj" <mhal@rbox.co>,
	"Mina Almasry" <almasrymina@google.com>,
	"Eric Biggers" <ebiggers@google.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Soheil Hassas Yeganeh" <soheil@google.com>,
	"Alexander Duyck" <alexanderduyck@fb.com>,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH net v1] net: skb: fix cross-cache free of KFENCE-allocated skb head
Date: Thu, 2 Apr 2026 12:15:31 +0800	[thread overview]
Message-ID: <ad90b2a9-0f67-4796-94bc-9dbb76a575af@linux.dev> (raw)
In-Reply-To: <CANn89iLdRZd-qO4tRpSGamHpggh=r5vM4xes5npYCnkwcNG89A@mail.gmail.com>


On 4/2/26 12:01 PM, Eric Dumazet wrote:
> On Wed, Apr 1, 2026 at 8:32 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>> SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2
>> value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc
>> bucket sizes. This ensures that skb_kfree_head() can reliably use
>> skb_end_offset to distinguish skb heads allocated from
>> skb_small_head_cache vs. generic kmalloc caches.
>>
>> However, when KFENCE is enabled, kfence_ksize() returns the exact
>> requested allocation size instead of the slab bucket size. If a caller
>> (e.g. bpf_test_init) allocates skb head data via kzalloc() and the
>> requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then
>> slab_build_skb() → ksize() returns that exact value. After subtracting
>> skb_shared_info overhead, skb_end_offset ends up matching
>> SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free
>> the object to skb_small_head_cache instead of back to the original
>> kmalloc cache, resulting in a slab cross-cache free:
>>
>>    kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected
>>    skbuff_small_head but got kmalloc-1k
>>
>> Fix this by adding an is_kfence_address() check in skb_kfree_head().
>> When the head is a KFENCE object, we skip the kmem_cache_free() path
>> and fall through to kfree(), which correctly handles KFENCE objects
>> via kfence_free(). The check compiles away when CONFIG_KFENCE is
>> disabled.
>>
>> Fixes: bf9f1baa279f ("net: add dedicated kmem_cache for typical/small skb->head")
>> Reported-by: Antonius <antonius@bluedragonsec.com>
>> Closes: https://lore.kernel.org/netdev/CAK8a0jxC5L5N7hq-DT2_NhUyjBxrPocoiDazzsBk4TGgT1r4-A@mail.gmail.com/
>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>> ---
>>   net/core/skbuff.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index 0e217041958a..87cecd40381b 100644
>> --- a/net/core/skbuff.c
>> +++ b/net/core/skbuff.c
>> @@ -91,6 +91,7 @@
>>   #include <linux/user_namespace.h>
>>   #include <linux/indirect_call_wrapper.h>
>>   #include <linux/textsearch.h>
>> +#include <linux/kfence.h>
>>
>>   #include "dev.h"
>>   #include "devmem.h"
>> @@ -1083,7 +1084,8 @@ static int skb_pp_frag_ref(struct sk_buff *skb)
>>
>>   static void skb_kfree_head(void *head, unsigned int end_offset)
>>   {
>> -       if (end_offset == SKB_SMALL_HEAD_HEADROOM)
>> +       if (end_offset == SKB_SMALL_HEAD_HEADROOM &&
>> +           !is_kfence_address(head))
>>                  kmem_cache_free(net_hotdata.skb_small_head_cache, head);
>>          else
>>                  kfree(head);
> Oh well, time to simply call kfree(head) ?
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 3d6978dd0aa83f63984b994359d0c914c6427a00..6b35aed23b8936409f6b0d4ee8d378f726c569c6
> 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -1072,10 +1072,7 @@ static int skb_pp_frag_ref(struct sk_buff *skb)
>
>   static void skb_kfree_head(void *head, unsigned int end_offset)
>   {
> -       if (end_offset == SKB_SMALL_HEAD_HEADROOM)
> -               kmem_cache_free(net_hotdata.skb_small_head_cache, head);
> -       else
> -               kfree(head);
> +       kfree(head);
>   }
>
>   static void skb_free_head(struct sk_buff *skb)


If we no longer care about the cost of accessing a struct page in the
free path, which the original commit was trying to avoid, this is
indeed the simplest fix — kfree() correctly handles objects via 
virt_to_slab.


  reply	other threads:[~2026-04-02  4:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02  3:31 [PATCH net v1] net: skb: fix cross-cache free of KFENCE-allocated skb head Jiayuan Chen
2026-04-02  4:01 ` Eric Dumazet
2026-04-02  4:15   ` Jiayuan Chen [this message]
2026-04-02  8:03     ` Eric Dumazet
2026-04-02  8:38       ` Jiayuan Chen

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=ad90b2a9-0f67-4796-94bc-9dbb76a575af@linux.dev \
    --to=jiayuan.chen@linux.dev \
    --cc=alexanderduyck@fb.com \
    --cc=almasrymina@google.com \
    --cc=antonius@bluedragonsec.com \
    --cc=bpf@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=ebiggers@google.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kerneljasonxing@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhal@rbox.co \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=soheil@google.com \
    --cc=toke@redhat.com \
    /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.