CVE-2026-98371

In the Linux kernel, the following vulnerability has been resolved:

xfrm: iptfs: fix runt reassembly panic from short inner tot len

When the start of an inner packet is split across two outer packets such that fewer than 4 bytes land at the end of the first one, input process payload() saves those bytes as a runt and skips the iplen/iphlen validation performed for in-place packets. When the continuation packet arrives, iptfs reassem cont() only requires the declared inner length to be >= sizeof(ra runt) (6) before allocating the reassembly skb with that attacker-controlled length.

However, iptfs iphlen() always returns the fixed minimum IP header size (20 for IPv4, 40 for IPv6), so for an inner IPv4 tot len in [6, 19] the header-completion copy writes past the declared packet length, and the subsequent "ipremain -= copylen" underflows to ~4GB, leaving the payload copy length bounded only by blkoff (up to 64KB). At runtime the skb put() tailroom check turns this into skb over panic(), i.e. an unprivileged kernel panic (DoS), reachable locally via userns+netns IPTFS SAs and remotely against IPTFS VPN gateways when the decrypted outer skb is linear (e.g. AF PACKET taps, tun/tap delivery).

Align the runt path with the normal path by requiring the declared inner length to cover at least the IP header size. This also subsumes the previous >= sizeof(ra runt) check, since the minimum IP header is always larger than the runt buffer.

This issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.