Kernel stops host panic on bad virtio UDP tunnel GSO frames

Eric Dumazet has posted fixes for the Linux networking stack that close a host crash in virtio-net and tun when UDP tunnel GSO packets carry outer headers that do not match their declared tunnel type.

The path that turns a virtio tunnel header into an skb did not confirm that a packet advertised as an IPv4 or IPv6 UDP tunnel actually began with matching outer IP and UDP headers. A guest, or any writer to a tap device, could supply a different outer ethertype, such as NSH. Segmentation offload would then push headers before the buffer head and trip skb_under_panic on the host.

The core change rejects those mismatched frames before GSO runs. Related fixes stop the code from deciding whether a frame starts with Ethernet by reading the device type alone: TUNSETLINK can retarget a down tun or tap device without changing how frames are framed, which previously let bad outer headers slip past the new checks. Another change clears a stale protocol value left on skbs recycled through NAPI frags, which could make valid tunnel frames look wrong or send checksum handling down the wrong path.

Several of those edge cases, including the TUNSETLINK bypass, the recycled-skb protocol leak, missing IPv6 and VLAN rejection coverage, and big-endian selftest bugs around tunnel offsets, were surfaced by Sashiko. Willem de Bruijn reviewed the work. Dumazet said a follow-up revision will fold the framing fix into the main validation change and hold the selftests for a later series.

Hosts that expose virtio-net or tun/tap with UDP tunnel GSO offloads to untrusted guests or userspace were at risk: a crafted frame could panic the machine instead of being dropped.