CVE-2026-98955: flow_dissector: avoid u16 truncation of skb->len when computing thoff

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

flowdissector: avoid u16 truncation of skb->len when computing thoff

skbflowdissect() computes keycontrol->thoff using:

keycontrol->thoff = mint(u16, nhoff, skb ? skb->len : hlen);

mint(u16, ...) casts both arguments to u16 before comparing them. Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the truncated length wins and thoff is set to a bogus small value, even when the dissection succeeded. For example, an IPv4/TCP frame with skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as skbprobetransportheader() point the transport header inside the Ethernet header.

Such skbs are not exotic: - At the time of commit d0c081b49137 ("flowdissector: properly cap thoff field"), AFPACKET with PACKETVNETHDR could already build GSO skbs larger than 64KB (MTU checks are skipped for GSO, and allocskbwithfrags() accepted up to MAXSKBFRAGS (17) order-0 pages on top of the linear part). - BIG TCP now makes skbs larger than 64KB common. - The following patch makes tungetuser() dissect IFFTAP frames before ethtypetrans() pulls the Ethernet header, so a GSO frame carrying a 65522..65535 byte L3 packet will be dissected with skb->len in [65536, 65549].

Compare as u32 instead. If the resulting offset cannot be represented in the u16 keycontrol->thoff, cap it to U16MAX and report the dissection as failed rather than silently returning a wrong transport offset. thoff is still set on failure, as some callers (such as ethgetheadlen()) use it regardless of the return value.