Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <220fc36ba1086c1390ba087d08561b61762c965a.camel@redhat.com>
Subject: Re: [PATCH v3] drivers: net: prevent tun_get_user() to exceed xdp
 size limits
From:   Paolo Abeni <pabeni@redhat.com>
To:     Jason Wang <jasowang@redhat.com>, David Ahern <dsahern@gmail.com>
Cc:     Jesper Dangaard Brouer <jbrouer@redhat.com>,
        Andrew Kanner <andrew.kanner@gmail.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>
Date:   Thu, 27 Jul 2023 11:30:43 +0200
In-Reply-To: <CACGkMEsYzd1FphP-Ym9T9YjA9ZNBw7Mnw5xQ75dytQMJxDK3cg@mail.gmail.com>
References: <20230725155403.796-1-andrew.kanner@gmail.com>
         <CACGkMEt=Cd8J995+0k=6MT1Pj=Fk9E_r2eZREptLt2osj_H-hA@mail.gmail.com>
         <ab722ec1-ae45-af1f-b869-e7339402c852@redhat.com>
         <179979e6-eb8a-0300-5445-999b9366250a@gmail.com>
         <0c06b067-349c-9fe2-2cc3-36c149fd5277@gmail.com>
         <CACGkMEsYzd1FphP-Ym9T9YjA9ZNBw7Mnw5xQ75dytQMJxDK3cg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Thu, 2023-07-27 at 14:07 +0800, Jason Wang wrote:
> On Thu, Jul 27, 2023 at 8:27=E2=80=AFAM David Ahern <dsahern@gmail.com> w=
rote:
> >=20
> > 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
> > > >=20
> > > > On 26/07/2023 04.09, Jason Wang wrote:
> > > > > On Tue, Jul 25, 2023 at 11:54=E2=80=AFPM Andrew Kanner
> > > > > <andrew.kanner@gmail.com> wrote:
> > > > > >=20
> > > > > > Syzkaller reported the following issue:
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > Too BIG xdp->frame_sz =3D 131072
> > > >=20
> > > > Is this a contiguous physical memory allocation?
> > > >=20
> > > > 131072 bytes equal order 5 page.
> > > >=20
> > > > 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 gues=
s it
> > > > is the netif_receive_generic_xdp() what will realloc to make this l=
inear
> > > > (via skb_linearize())
> > >=20
> > >=20
> > > 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. T=
hat
> > > 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. Tha=
t
> > > causes bpf_prog_run_generic_xdp to compute the wrong frame_sz.
> >=20
> >=20
> > 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=
.
> >=20
> > 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 th=
e
> > splat is about.
>=20
> Other possibility:
>=20
> 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().
>=20
> 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().
>=20
> >=20
> > Perhaps the solution is to remove the WARN_ON.
>=20
> 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