From: Andrew Kanner <andrew.kanner@gmail.com>
To: David Ahern <dsahern@gmail.com>
Cc: syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.com,
netdev@vger.kernel.org, Jason Wang <jasowang@redhat.com>,
John Fastabend <john.fastabend@gmail.com>,
linux-kernel@vger.kernel.org,
Jesper Dangaard Brouer <jbrouer@redhat.com>,
edumazet@google.com, brouer@redhat.com, kuba@kernel.org,
Paolo Abeni <pabeni@redhat.com>,
linux-kernel-mentees@lists.linuxfoundation.org,
davem@davemloft.net
Subject: Re: [PATCH v3] drivers: net: prevent tun_get_user() to exceed xdp size limits
Date: Mon, 31 Jul 2023 18:47:16 +0300 [thread overview]
Message-ID: <64c7d788.190a0220.3c2cf.5d7f@mx.google.com> (raw)
In-Reply-To: <cf1ef905-fa48-df3a-2d3c-37d7a1e79b8e@gmail.com>
On Thu, Jul 27, 2023 at 06:11:57PM -0600, David Ahern wrote:
> On 7/27/23 5:48 PM, Andrew Kanner wrote:
> >
> > Thanks, everyone.
> >
> > If we summarize the discussion - there are 3 issues here:
> > 1. tun_can_build_skb() doesn't count XDP_PACKET_HEADROOM (minor and
> > most trivial)
> > 2. WARN_ON_ONCE from net/core/filter.c, which may be too strict / not
> > needed at all.
> > 3. strange behaviour with reallocationg SKB (65007 -> 131072)
>
> I believe that happens because of the current skb size and the need to
> expand it to account for the XDP headroom makes the allocation go over
> 64kB. Since tun is given the packet via a write call there are no header
> markers to allocate separate space for headers and data (e.g. like TCP
> does with 32kB data segments).
Yes, this is exactly what you suspected. In pskb_expand_head() ->
kmalloc_reserve() I have these values initially:
(gdb) p *size
$13 = 65408
(gdb) p obj_size
$16 = 65728
and it will do:
data = kmalloc_reserve(&size, gfp_mask, NUMA_NO_NODE, NULL);
...
obj_size = SKB_HEAD_ALIGN(*size);
...
*size = obj_size = kmalloc_size_roundup(obj_size);
(gdb) p *size
$22 = 131072
So this is kmalloc_size_roundup() doing this math with the following:
/* Above the smaller buckets, size is a multiple of page size. */ │
if (size > KMALLOC_MAX_CACHE_SIZE) │
return PAGE_SIZE << get_order(size);
> >
> > I can check these issues. I have to dive a little deeper with 2-3,
> > most likely with kgdb and syzkaller repro. But seems this is not
> > somewhat urgent and lives quite a long time without being noticed.
> >
> > BTW: Attached the ftrace logs using the original syzkaller repro
> > (starting with tun_get_user()). They answer Jesper's question about
> > contiguous physical memory allocation (kmem_cache_alloc_node() /
> > kmalloc_reserve()). But I'll check it one more time before submitting
> > a new PATCH V4 or another patch / patch series.
> >
>
I see no other bugs in math, so not sure wether it should be fixed. Is
it ok and expected to roundup the memory allocation?
--
Andrew Kanner
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Kanner <andrew.kanner@gmail.com>
To: David Ahern <dsahern@gmail.com>
Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>,
Paolo Abeni <pabeni@redhat.com>, Jason Wang <jasowang@redhat.com>,
brouer@redhat.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linuxfoundation.org,
syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.com,
John Fastabend <john.fastabend@gmail.com>
Subject: Re: [PATCH v3] drivers: net: prevent tun_get_user() to exceed xdp size limits
Date: Mon, 31 Jul 2023 18:47:16 +0300 [thread overview]
Message-ID: <64c7d788.190a0220.3c2cf.5d7f@mx.google.com> (raw)
In-Reply-To: <cf1ef905-fa48-df3a-2d3c-37d7a1e79b8e@gmail.com>
On Thu, Jul 27, 2023 at 06:11:57PM -0600, David Ahern wrote:
> On 7/27/23 5:48 PM, Andrew Kanner wrote:
> >
> > Thanks, everyone.
> >
> > If we summarize the discussion - there are 3 issues here:
> > 1. tun_can_build_skb() doesn't count XDP_PACKET_HEADROOM (minor and
> > most trivial)
> > 2. WARN_ON_ONCE from net/core/filter.c, which may be too strict / not
> > needed at all.
> > 3. strange behaviour with reallocationg SKB (65007 -> 131072)
>
> I believe that happens because of the current skb size and the need to
> expand it to account for the XDP headroom makes the allocation go over
> 64kB. Since tun is given the packet via a write call there are no header
> markers to allocate separate space for headers and data (e.g. like TCP
> does with 32kB data segments).
Yes, this is exactly what you suspected. In pskb_expand_head() ->
kmalloc_reserve() I have these values initially:
(gdb) p *size
$13 = 65408
(gdb) p obj_size
$16 = 65728
and it will do:
data = kmalloc_reserve(&size, gfp_mask, NUMA_NO_NODE, NULL);
...
obj_size = SKB_HEAD_ALIGN(*size);
...
*size = obj_size = kmalloc_size_roundup(obj_size);
(gdb) p *size
$22 = 131072
So this is kmalloc_size_roundup() doing this math with the following:
/* Above the smaller buckets, size is a multiple of page size. */ │
if (size > KMALLOC_MAX_CACHE_SIZE) │
return PAGE_SIZE << get_order(size);
> >
> > I can check these issues. I have to dive a little deeper with 2-3,
> > most likely with kgdb and syzkaller repro. But seems this is not
> > somewhat urgent and lives quite a long time without being noticed.
> >
> > BTW: Attached the ftrace logs using the original syzkaller repro
> > (starting with tun_get_user()). They answer Jesper's question about
> > contiguous physical memory allocation (kmem_cache_alloc_node() /
> > kmalloc_reserve()). But I'll check it one more time before submitting
> > a new PATCH V4 or another patch / patch series.
> >
>
I see no other bugs in math, so not sure wether it should be fixed. Is
it ok and expected to roundup the memory allocation?
--
Andrew Kanner
next prev parent reply other threads:[~2023-07-31 15:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 15:54 [PATCH v3] drivers: net: prevent tun_get_user() to exceed xdp size limits Andrew Kanner
2023-07-25 15:54 ` Andrew Kanner
2023-07-26 2:09 ` Jason Wang
2023-07-26 2:09 ` Jason Wang
2023-07-26 7:20 ` Andrew Kanner
2023-07-26 7:20 ` Andrew Kanner
2023-07-26 9:02 ` Jesper Dangaard Brouer
2023-07-26 9:02 ` Jesper Dangaard Brouer
2023-07-26 19:37 ` David Ahern
2023-07-26 19:37 ` David Ahern
2023-07-27 0:27 ` David Ahern
2023-07-27 0:27 ` David Ahern
2023-07-27 6:07 ` Jason Wang
2023-07-27 6:07 ` Jason Wang
2023-07-27 9:30 ` Paolo Abeni
2023-07-27 9:30 ` Paolo Abeni
2023-07-27 11:13 ` Jesper Dangaard Brouer
2023-07-27 11:13 ` Jesper Dangaard Brouer
2023-07-27 23:48 ` Andrew Kanner
2023-07-27 23:48 ` Andrew Kanner
2023-07-28 0:11 ` David Ahern
2023-07-28 0:11 ` David Ahern
2023-07-31 15:47 ` Andrew Kanner [this message]
2023-07-31 15:47 ` Andrew Kanner
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=64c7d788.190a0220.3c2cf.5d7f@mx.google.com \
--to=andrew.kanner@gmail.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=jasowang@redhat.com \
--cc=jbrouer@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.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.