Willem de Bruijn wrote:
But so the real bug, an skb with 4B in the UDP layer happens beforeOh of course, this is udp fragmentation offload (UFO):
that.
An skb_dump in udp_queue_rcv_skb of the GSO skb shows
[ 174.151409] skb len=190 headroom=64 headlen=190 tailroom=66
[ 174.151409] mac=(64,14) mac_len=14 net=(78,20) trans=98
[ 174.151409] shinfo(txflags=0 nr_frags=0 gso(size=4 type=65538 segs=0))
[ 174.151409] csum(0x8c start=140 offset=0 ip_summed=3 complete_sw=0 valid=1 level=0)
[ 174.151409] hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=2 iif=8
[ 174.151409] priority=0x0 mark=0x0 alloc_cpu=1 vlan_all=0x0
[ 174.151409] encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)
[ 174.152101] dev name=tun0 feat=0x00002000000048c1
And of segs[0] after segmentation
[ 103.081442] skb len=38 headroom=64 headlen=38 tailroom=218
[ 103.081442] mac=(64,14) mac_len=14 net=(78,20) trans=98
[ 103.081442] shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
[ 103.081442] csum(0x8c start=140 offset=0 ip_summed=1 complete_sw=0 valid=1 level=0)
[ 103.081442] hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=2 iif=8
[ 103.081442] priority=0x0 mark=0x0 alloc_cpu=0 vlan_all=0x0
[ 103.081442] encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)
So here translen is already 38 - (98-64) == 38 - 34 == 4.
So the bug happens in segmentation.
[ongoing ..]
VIRTIO_NET_HDR_GSO_UDP.
So only the first packet has an UDP header, and that explains why the
other packets are only 4B.
They are not UDP packets, but they have already entered the UDP stack
due to this being GSO applied in udp_queue_rcv_skb.
That was never intended to be used for UFO. Only for GRO, which does
not build such packets.
Maybe we should just drop UFO (SKB_GSO_UDP) packets in this code path?