From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willem de Bruijn Subject: Re: [PATCH net] net: validate untrusted gso packets Date: Tue, 16 Jan 2018 23:56:33 -0500 Message-ID: References: <20180116202914.205914-1-willemdebruijn.kernel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: Network Development , David Miller , Eric Dumazet , Willem de Bruijn To: Jason Wang Return-path: Received: from mail-oi0-f67.google.com ([209.85.218.67]:44748 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751859AbeAQE5O (ORCPT ); Tue, 16 Jan 2018 23:57:14 -0500 Received: by mail-oi0-f67.google.com with SMTP id g128so12248331oib.11 for ; Tue, 16 Jan 2018 20:57:13 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Jan 16, 2018 at 11:33 PM, Willem de Bruijn wrote: > On Tue, Jan 16, 2018 at 11:04 PM, Jason Wang wrote: >> >> >> On 2018=E5=B9=B401=E6=9C=8817=E6=97=A5 04:29, Willem de Bruijn wrote: >>> >>> From: Willem de Bruijn >>> >>> Validate gso packet type and headers on kernel entry. Reuse the info >>> gathered by skb_probe_transport_header. >>> >>> Syzbot found two bugs by passing bad gso packets in packet sockets. >>> Untrusted user packets are limited to a small set of gso types in >>> virtio_net_hdr_to_skb. But segmentation occurs on packet contents. >>> Syzkaller was able to enter gso callbacks that are not hardened >>> against untrusted user input. >> >> >> Do this mean there's something missed in exist header check for dodgy >> packets? > > virtio_net_hdr_to_skb checks gso_type, but it does not verify that this > type correctly describes the actual packet. Segmentation happens based > on packet contents. So a packet was crafted to enter sctp gso, even > though no such gso_type exists. This issue is not specific to sctp. > >>> >>> User packets can also have corrupted headers, tripping up segmentation >>> logic that expects sane packets from the trusted protocol stack. >>> Hardening all segmentation paths against all bad packets is error >>> prone and slows down the common path, so validate on kernel entry. >> >> >> I think evil packets should be rare in common case, so I'm not sure vali= date >> it on kernel entry is a good choice especially consider we've already ha= d >> header check. > > This just makes that check more strict. Frequency of malicious packets is > not really relevant if a single bad packet can cause damage. > > The alternative to validate on kernel entry is to harden the entire segme= ntation > layer and lower part of the stack. That is much harder to get right and n= ot > necessarily cheaper. > > As a matter of fact, it incurs a cost on all packets, including the commo= n > case generated by the protocol stack. If packets can be fully validated at the source, we can eventually also get rid of the entire SKB_GSO_DODGY and NETIF_F_GSO_ROBUST logic. Then virtio packets won't have to enter the segmentation layer at all for TSO capable devices.