Messages in this thread | | | Date | Wed, 26 Jul 2023 18:27:12 -0600 | Subject | Re: [PATCH v3] drivers: net: prevent tun_get_user() to exceed xdp size limits | From | David Ahern <> |
| |
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.
| |