CVE-2026-98371: xfrm: iptfs: fix runt reassembly panic from short inner tot_len
In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: fix runt reassembly panic from short inner totlen
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, inputprocesspayload() saves those bytes as a runt and skips the iplen/iphlen validation performed for in-place packets. When the continuation packet arrives, iptfsreassemcont() only requires the declared inner length to be >= sizeof(rarunt) (6) before allocating the reassembly skb with that attacker-controlled length.
However, iptfsiphlen() always returns the fixed minimum IP header size (20 for IPv4, 40 for IPv6), so for an inner IPv4 totlen 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 skbput() tailroom check turns this into skboverpanic(), 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. AFPACKET 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(rarunt) 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
Systems using IPTFS security associations are affected in two described scenarios: local use through user and network namespaces, and IPTFS VPN gateways processing remote traffic. Remote reachability additionally depends on the decrypted outer skb being linear, such as with AF_PACKET taps or tun/tap devices.
What does an attacker need to send or control to trigger the failure?
The attacker needs to cause an inner packet header to be split across outer packets with fewer than four bytes at the end of the first packet, then provide a continuation declaring an inner IPv4 total length from 6 through 19 bytes. Locally, this is reachable by an unprivileged user through userns and netns IPTFS SAs.
What is the practical impact of successful exploitation?
The malformed reassembly causes an skb tailroom check to fail and triggers skb_over_panic(). This results in an unprivileged kernel panic and denial of service.