netdev - Re: [PATCH bpf-next] bpf: fix memory leak in bpf_lwt_xmit

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]

Date:   Sun, 3 Mar 2019 21:54:39 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Peter Oskolkov <posk@...gle.com>, Peter Oskolkov <posk@...k.io>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next] bpf: fix memory leak in bpf_lwt_xmit_reroute

On Fri, Mar 1, 2019 at 9:27 PM David Ahern <dsahern@...il.com> wrote:
>
> On 2/28/19 10:57 AM, Peter Oskolkov wrote:
> > David: I'm not sure how to test GSO (I assume we are talking about GSO
> > here) in
> > the selftest: the encapping code sets SKB_GSO_DODGY flag, and veth does
> > not support
> > dodginess: "tx-gso-robust: off [fixed]".
> >
> > If the "dodgy" flag is not set, then gso validation in dev.c passes, and
> > large GSO packets
> > happily go through; if the "dodgy" flag is set, "dodgy" GSO packets are
> > rejected, TCP does
> > segmentation, and non-GSO packets happily go through (with an mtu tweak
> > to the LWT tunnel).

Very few devices unconditionally accept dodgy packets (only veth?).

A device that lacks the robust gso feature will cause a gso packet
with dodgy flag to enter software gso instead of passing to device
segmentation offload.

That should be perfect for checking that the packets can be segmented
correctly with the new header.

If the gso layer drops the packets, that is not due to dropping all
dodgy sources. It will be dropped somewhere else inside gso,
indication that something is not as expected with the packet.

> > So I see three options:
> > - add a sysctl to _not_ set SKB_GSO_DODGY flag in lwt_bpf.c =>
> > handle_gso_type();
> > - change veth to accept "dodgy" GSO packets

Neither, as these would bypass segmentation offload and pass the large
packet to the receive path. It is more interesting to validate the
packet in gso.

> > - test the code "as is", meaning that GSO will be tried and disabled by
> > TCP stack
> >
> > Which approach would you prefer?
> >
>
> definitely not a sysctl.
>
> After that, I don't have a suggestion for GSO at the moment.