All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Jesper Dangaard Brouer <jbrouer@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Andrew Kanner <andrew.kanner@gmail.com>
Cc: syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.com,
	netdev@vger.kernel.org, John Fastabend <john.fastabend@gmail.com>,
	linux-kernel@vger.kernel.org, edumazet@google.com,
	brouer@redhat.com, kuba@kernel.org, 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: Wed, 26 Jul 2023 18:27:12 -0600	[thread overview]
Message-ID: <0c06b067-349c-9fe2-2cc3-36c149fd5277@gmail.com> (raw)
In-Reply-To: <179979e6-eb8a-0300-5445-999b9366250a@gmail.com>

On 7/26/23 1:37 PM, David Ahern wrote:
> On 7/26/23 3:02 AM, Jesper Dangaard Brouer wrote:
>> Cc. John and Ahern
>>
>> On 26/07/2023 04.09, Jason Wang wrote:
>>> On Tue, Jul 25, 2023 at 11:54 PM Andrew Kanner
>>> <andrew.kanner@gmail.com> wrote:
>>>>
>>>> Syzkaller reported the following issue:
>>>> =======================================
>>>> Too BIG xdp->frame_sz = 131072
>>
>> Is this a contiguous physical memory allocation?
>>
>> 131072 bytes equal order 5 page.
>>
>> Looking at tun.c code I cannot find a code path that could create
>> order-5 skb->data, but only SKB with order-0 fragments.  But I guess it
>> is the netif_receive_generic_xdp() what will realloc to make this linear
>> (via skb_linearize())
> 
> 
> get_tun_user is passed an iov_iter with a single segment of 65007
> total_len. The alloc_skb path is hit with an align size of only 64. That
> is insufficient for XDP so the netif_receive_generic_xdp hits the
> pskb_expand_head path. Something is off in the math in
> netif_receive_generic_xdp resulting in the skb markers being off. That
> causes bpf_prog_run_generic_xdp to compute the wrong frame_sz.


BTW, it is pskb_expand_head that turns it from a 64kB to a 128 kB
allocation. But the 128kB part is not relevant to the "bug" here really.

The warn on getting tripped in bpf_xdp_adjust_tail is because xdp
generic path is skb based and can have a frame_sz > 4kB. That's what the
splat is about.

Perhaps the solution is to remove the WARN_ON.


_______________________________________________
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: David Ahern <dsahern@gmail.com>
To: Jesper Dangaard Brouer <jbrouer@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Andrew Kanner <andrew.kanner@gmail.com>
Cc: brouer@redhat.com, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, 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: Wed, 26 Jul 2023 18:27:12 -0600	[thread overview]
Message-ID: <0c06b067-349c-9fe2-2cc3-36c149fd5277@gmail.com> (raw)
In-Reply-To: <179979e6-eb8a-0300-5445-999b9366250a@gmail.com>

On 7/26/23 1:37 PM, David Ahern wrote:
> On 7/26/23 3:02 AM, Jesper Dangaard Brouer wrote:
>> Cc. John and Ahern
>>
>> On 26/07/2023 04.09, Jason Wang wrote:
>>> On Tue, Jul 25, 2023 at 11:54 PM Andrew Kanner
>>> <andrew.kanner@gmail.com> wrote:
>>>>
>>>> Syzkaller reported the following issue:
>>>> =======================================
>>>> Too BIG xdp->frame_sz = 131072
>>
>> Is this a contiguous physical memory allocation?
>>
>> 131072 bytes equal order 5 page.
>>
>> Looking at tun.c code I cannot find a code path that could create
>> order-5 skb->data, but only SKB with order-0 fragments.  But I guess it
>> is the netif_receive_generic_xdp() what will realloc to make this linear
>> (via skb_linearize())
> 
> 
> get_tun_user is passed an iov_iter with a single segment of 65007
> total_len. The alloc_skb path is hit with an align size of only 64. That
> is insufficient for XDP so the netif_receive_generic_xdp hits the
> pskb_expand_head path. Something is off in the math in
> netif_receive_generic_xdp resulting in the skb markers being off. That
> causes bpf_prog_run_generic_xdp to compute the wrong frame_sz.


BTW, it is pskb_expand_head that turns it from a 64kB to a 128 kB
allocation. But the 128kB part is not relevant to the "bug" here really.

The warn on getting tripped in bpf_xdp_adjust_tail is because xdp
generic path is skb based and can have a frame_sz > 4kB. That's what the
splat is about.

Perhaps the solution is to remove the WARN_ON.



  reply	other threads:[~2023-07-27  0:27 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 [this message]
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
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=0c06b067-349c-9fe2-2cc3-36c149fd5277@gmail.com \
    --to=dsahern@gmail.com \
    --cc=andrew.kanner@gmail.com \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --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.