Messages in this thread | | | Subject | Re: [PATCH v3] drivers: net: prevent tun_get_user() to exceed xdp size limits | From | Paolo Abeni <> | Date | Thu, 27 Jul 2023 11:30:43 +0200 |
| |
On Thu, 2023-07-27 at 14:07 +0800, Jason Wang wrote: > On Thu, Jul 27, 2023 at 8:27 AM David Ahern <dsahern@gmail.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@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. > > 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.
I understand the consensus is solving the issue by changing/removing the WARN_ON() in XDP. I think it makes sense, I guess the same warn can be reached via packet socket xmit on veth or similar topology.
Cheers,
Paolo
| |