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]
Message-ID: <CAF=yD-Ja4=czznVeJmp=G0Hwd56whmfmx6p1sOYtr-mSn46sjw@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ