netdev - Re: BUG:af_packet fails to TX TSO frames

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:   Wed, 11 Oct 2017 14:57:50 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Anton Ivanov <anton.ivanov@...-begemot.co.uk>
Cc:     Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>
Subject: Re: BUG:af_packet fails to TX TSO frames

On Wed, Oct 11, 2017 at 2:39 PM, Anton Ivanov
<anton.ivanov@...-begemot.co.uk> wrote:
> The check as now insists that the actual driver supports GSO_ROBUST, because
> we have marked the skb dodgy.
>
> The specific bit which does this check is in net_gso_ok()
>
> Now, lets's see how many Ethernet drivers set GSO_ROBUST.
>
> find drivers/net/ethernet -type f -name "*.[c,h]" -exec grep -H GSO_ROBUST
> {} \;
>
> That returns nothing in 4.x
>
> IMHO - af_packet allocates the skb, does all checks (and extra may be added)
> on the gso, why is this set dodgy in the first place?

It is set when the header has to be validated.

The segmentation logic will validate and fixup gso_segs. See for
instance tcp_gso_segment:

        if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) {
                /* Packet is from an untrusted source, reset gso_segs. */

                skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);

                segs = NULL;
                goto out;
        }

If the device would have the robust bit set and otherwise supports the
required features, fix up gso_segs and pass the large packet to the
device.

Else it continues to the software gso path.

Large packets generated with psock_txring_vnet.c pass this test. I
suspect that there is a subtle difference in the virtio_net_hdr fields
that that generates vs. your program.