netdev - Re: [PATCH net v2] gso: validate gso_type if SKB_GSO

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:   Fri, 19 Jan 2018 09:25:45 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Tom Herbert <tom@...bertland.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net v2] gso: validate gso_type if SKB_GSO_DODGY

On Fri, Jan 19, 2018 at 7:36 AM, Jason Wang <jasowang@...hat.com> wrote:
>
>
> On 2018年01月19日 08:19, Willem de Bruijn wrote:
>>
>> From: Willem de Bruijn<willemb@...gle.com>
>>
>> Validate gso_type during segmentation as SKB_GSO_DODGY sources
>> may pass packets where the gso_type does not match the contents.
>>
>> Syzkaller was able to enter the SCTP gso handler with a packet of
>> gso_type SKB_GSO_TCPV4.
>>
>> On entry of transport layer gso handlers, verify that the gso_type
>> matches the transport protocol.
>>
>> Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
>> Link:http://lkml.kernel.org/r/<001a1137452496ffc305617e5fe0@...gle.com>
>> Reported-by:syzbot+fee64147a25aecd48055@...kaller.appspotmail.com
>> Signed-off-by: Willem de Bruijn<willemb@...gle.com>
>
>
> Thanks, just two nits:
>
> 1) I still suspect the "Fixes" is not accurate, should it be the commit of
> sctp offloading?

That commit c5c4e45c4b79 ("sctp: fix GSO for IPv6") is older than the
equivalent for ESP, so catches both protocols that were added since the
TSO checks were removed.

It implies that TCP and UFO are robust against packets of wrong
transport protocol. As the previous TSO checks did not cover software
GSO, either, I suppose we can assume that.

With that caveat: okay, I will change it.

> 2) The patch checks for non dodgy packets too so the title is not correct.

Ack, will change to.

Thanks