CVE-2026-98372

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

xfrm: iptfs: fix stack OOB read in iptfs skb reset frag walk()

iptfs skb reset frag walk() advances to the fragment containing @offset with an unbounded loop:

while (offset >= walk->past + walk->frags[walk->fragi].len)
	walk->past += walk->frags[walk->fragi++].len;

walk->fragi is advanced and walk->frags[walk->fragi] is dereferenced without ever checking fragi against walk->nr frags. When the requested offset is at or beyond the total length spanned by the walk's fragments, fragi runs past nr frags and off the end of the fixed-size on-stack frags[MAX SKB FRAGS + 1] array, reading out-of-bounds stack memory.

The two callers behave differently: iptfs skb add frags() already guards against this with

if (!walk->nr frags ||
  offset >= walk->total + walk->initial offset)
	return len;

but iptfs skb can add frags() has no such guard and calls iptfs skb reset frag walk() unconditionally, so it performs the out-of-range walk. Its own "fragi < walk->nr frags" bound check runs only afterwards, too late to prevent the read.

This is reachable from the receive path: a crafted IP-TFS (AGGFRAG) payload delivered to an IPTFS SA drives iptfs reassem cont() -> iptfs skb can add frags() with an offset past the fragment total, e.g.:

BUG: KASAN: stack-out-of-bounds in iptfs skb reset frag walk+0x235/0x250 Read of size 4 at addr ffff888008ad7210 by task repro/345 iptfs skb reset frag walk+0x235/0x250 net/xfrm/xfrm iptfs.c:392 iptfs skb can add frags+0x155/0x310 net/xfrm/xfrm iptfs.c:420 iptfs reassem cont+0xcf8/0x1140 net/xfrm/xfrm iptfs.c:902 iptfs input ordered+0x552/0x670 net/xfrm/xfrm iptfs.c:1280 iptfs input+0x3d6/0xde0 net/xfrm/xfrm iptfs.c:1741 xfrm input+0x282f/0x6140 net/xfrm/xfrm input.c:700 xfrm4 esp rcv+0x93/0x120 net/ipv4/xfrm4 protocol.c:104 ip rcv+0x278/0x2d0 net/ipv4/ip input.c:612

Give iptfs skb can add frags() the same up-front guard that iptfs skb add frags() already has, so the walk is never entered with an out-of-range offset. When it triggers, the caller falls back to the existing linearize-and-copy path, which is safe.