PT-2026-116768 · Linux · Linux
CVE-2026-98549
·
Published
2026-10-18
·
Updated
2026-10-18
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
tcp: prevent collapsing skbs across boundary in rtx queue
tcp write collapse fence() sets TCP SKB CB(skb)->eor = 1 on
tcp write queue tail(sk) to prevent skbs queued after a switch to
device encryption from being collapsed into earlier skbs.
The fence is a no-op if all earlier data has already been transmitted
when the switch happens: sk->sk write queue is empty. The not yet
acknowledged earlier skbs wait in sk->tcp rtx queue with eor 0.
On a subsequent retransmit or SACK shift, tcp retrans try collapse() or
tcp shift skb data() can then merge an skb queued after the switch into
one queued before it.
Both users of the fence are affected:
-
psp: devices only encrypt skbs with skb->decrypted set. The merged skb keeps decrypted = 0 from the earlier skb, so merged data sent after psp sock assoc set tx() is retransmitted in cleartext.
-
tls device offload: the merged skb straddles the start marker set in tls set device offload(). The software fallback (fill sg in() returns -EINVAL) and the mlx5, nfp and funeth drivers cannot handle such an skb and drop it. Every retransmit rebuilds the same skb, so the connection stalls.
Fix this in two places, for defense in depth:
-
Fall back to tcp rtx queue tail(sk) in tcp write collapse fence() when tcp write queue tail(sk) is NULL.
-
Check !skb cmp decrypted(to, from) in tcp skb can collapse(), as tcp skb can collapse rx() does on receive. skb shift(), which both collapse paths call, already has a DEBUG NET WARN ON ONCE() for this condition.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux