netdev - Re: [PATCH net] net: validate untrusted gso packets

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, 17 Jan 2018 12:04:19 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        netdev@...r.kernel.org
Cc:     davem@...emloft.net, edumazet@...gle.com,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net] net: validate untrusted gso packets



On 2018年01月17日 04:29, Willem de Bruijn wrote:
> From: Willem de Bruijn<willemb@...gle.com>
>
> 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?

>
> 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 
validate it on kernel entry is a good choice especially consider we've 
already had header check.

>
> Introduce skb_probe_transport_header_hard to unconditionally probe,
> even if skb_partial_csum_set has already set an offset. That is under
> user control, so do not trust it. I did not see a measurable change
> in TCP_STREAM performance.
>
> Move tpacket probe call after virtio_net_hdr_to_skb has set gso_type.
>
> Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.")
> Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
> Fixes: f942dc2552b8 ("xen network backend driver")
> 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