Re: [PATCH net 0/1] net: reject IP sends with excessive headroom

[Ido Schimmel <idosch@nvidia.com>]

On Tue, Jul 28, 2026 at 02:03:05AM +0800, Ren Wei wrote:
> From: Zhiling Zou <zhilinz@nebusec.ai>
> Bug details:
> 
> IPv4 and IPv6 output paths reserve LL_RESERVED_SPACE(dev) before recording skb
> network and transport header offsets. Those offsets are stored in 16-bit skb
> fields.
> 
> A namespace-local stack of tunnel devices can make hard_header_len plus
> needed_headroom exceed the range of those fields. In rawv6_send_hdrinc(), the
> wrapped skb->network_header makes ipv6_hdr(skb) point back into headroom
> instead of the packet area just reserved by skb_put(). The user-supplied IPv6
> packet is copied to that wrapped header pointer while the actual packet data
> remains stale. Later IPv6 output and error handling can operate on invalid
> headers and crash, as seen in __skb_flow_dissect().
> 
> The same root cause is present in the ordinary IPv4 and IPv6 append/cork
> paths, which reserve device headroom and then store network_header plus
> fragheaderlen in skb->transport_header. IPv4 raw HDRINCL also adds the
> user-provided ihl to skb->transport_header after parsing the header.
> 
> The fix rejects IPv4 and IPv6 sends before the affected header offsets are
> stored if the largest offset for that path cannot be encoded in the skb header
> fields.

Instead of sprinkling checks in the data path, why not make sure that
net devices don't advertise bogus needed_headroom / hard_header_len
values in the control path? Commit 5ae1e9922bbd ("net: ip_tunnel:
prevent perpetual headroom growth") chose a value of 512, so maybe we
can use that.

AFAICT, the bug can only happen when stacking IP tunnels or when
creating a netkit device with a bogus headroom using
IFLA_NETKIT_HEADROOM.