On 2018年01月17日 04:29, Willem de Bruijn wrote:
From: Willem de Bruijn<will...@google.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/<001a1137452496ffc305617e5...@google.com>
Reported-by:syzbot+fee64147a25aecd48...@syzkaller.appspotmail.com
Signed-off-by: Willem de Bruijn<will...@google.com>
...
Thanks
