lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACGkMEsYzd1FphP-Ym9T9YjA9ZNBw7Mnw5xQ75dytQMJxDK3cg@mail.gmail.com>
Date:   Thu, 27 Jul 2023 14:07:38 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Jesper Dangaard Brouer <jbrouer@...hat.com>,
        Andrew Kanner <andrew.kanner@...il.com>, brouer@...hat.com,
        davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        syzbot+f817490f5bd20541b90a@...kaller.appspotmail.com,
        John Fastabend <john.fastabend@...il.com>
Subject: Re: [PATCH v3] drivers: net: prevent tun_get_user() to exceed xdp
 size limits

On Thu, Jul 27, 2023 at 8:27 AM David Ahern <dsahern@...il.com> wrote:
>
> 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@...il.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.

Other possibility:

tun_can_build_skb() doesn't count XDP_PACKET_HEADROOM this may end up
with producing a frame_sz which is greater than PAGE_SIZE as well in
tun_build_skb().

And rethink this patch, it looks wrong since it basically drops all
packets whose buflen is greater than PAGE_SIZE since it can't fall
back to tun_alloc_skb().

>
> Perhaps the solution is to remove the WARN_ON.

Yes, that is what I'm asking if this warning still makes sense in V1.

Thanks

>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ