CVE-2026-98549: Linux Kernel TCP Stack DoS Vulnerability

CVE-2026-98549 Overview

CVE-2026-98549 is a Linux kernel vulnerability in the TCP stack. The flaw affects tcp_write_collapse_fence(), a fence used to prevent sk_buff (skb) coalescing across encryption state transitions. When the write queue is empty at the moment of a switch to device encryption, the fence becomes a no-op. Subsequent retransmit or Selective Acknowledgment (SACK) shift operations may then merge post-switch skbs into pre-switch skbs in the retransmit queue. The result is cleartext transmission of data intended for Pre-Shared Key (PSP) protection or connection stalls under Transport Layer Security (TLS) device offload.

Critical Impact
Data intended for PSP encryption can be retransmitted in cleartext, and TLS device offload connections can stall indefinitely due to malformed skbs being dropped by hardware offload drivers.

Affected Products

Linux kernel builds using TCP PSP offload (psp_sock_assoc_set_tx())
Linux kernel builds using TLS device offload (tls_set_device_offload())
Drivers affected by malformed skb handling: mlx5, nfp, funeth

Discovery Timeline

2026-10-18 - CVE-2026-98549 published to the National Vulnerability Database (NVD)
2026-10-21 - Last updated in NVD database

Technical Details for CVE-2026-98549

Vulnerability Analysis

The vulnerability resides in the Linux kernel TCP output path, specifically in logic that handles skb coalescing across the retransmit queue. tcp_write_collapse_fence() sets TCP_SKB_CB(skb)->eor = 1 on tcp_write_queue_tail(sk) to mark an end-of-record boundary. This boundary prevents skbs queued after a switch to device encryption from being collapsed into earlier skbs.

The fence is only effective when sk->sk_write_queue contains unsent data at the time of the switch. If all earlier data has already been transmitted, the write queue is empty and the fence becomes a no-op. Unacknowledged earlier skbs remain 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 merge an skb queued after the switch into one queued before it. Two subsystems are impacted. For PSP, devices only encrypt skbs with skb->decrypted set; the merged skb inherits decrypted = 0, so post-switch data is retransmitted in cleartext. For TLS device offload, the merged skb straddles the start marker set by tls_set_device_offload(), causing the software fallback (fill_sg_in() returning -EINVAL) and the mlx5, nfp, and funeth drivers to drop it. Every retransmit rebuilds the same malformed skb, stalling the connection.

Root Cause

The root cause is a missing boundary check in two code paths. First, tcp_write_collapse_fence() does not fall back to tcp_rtx_queue_tail(sk) when tcp_write_queue_tail(sk) is NULL. Second, tcp_skb_can_collapse() does not compare the decrypted flag between candidate skbs, unlike its receive-side counterpart tcp_skb_can_collapse_rx().

Attack Vector

Triggering the condition requires an in-flight TCP connection that transitions to PSP or TLS device offload while the socket write queue is empty but the retransmit queue is non-empty. Packet loss or SACK shifts then drive the collapse. Exploitation is a function of network conditions and application I/O patterns rather than a direct remote primitive. The impact ranges from confidentiality loss (cleartext retransmission under PSP) to availability loss (connection stall under TLS offload).

No verified exploit code is available. See the upstream kernel commits referenced below for technical details and the applied patches.

Detection Methods for CVE-2026-98549

Indicators of Compromise

TCP connections using TLS device offload that enter persistent retransmit loops without progress on mlx5, nfp, or funeth interfaces.
Driver log messages or counters indicating dropped TX skbs following a TLS offload setup event.
Unexpected cleartext payload fragments on the wire for sockets that have invoked psp_sock_assoc_set_tx().

Detection Strategies

Audit running kernel versions against the fixed commits (08e835f, 1ae7aee, 7ba8750, 9e2a2f9, fc6d80e) across your fleet.
Instrument tracepoints on tcp_retrans_try_collapse and tcp_shift_skb_data to flag collapses across differing skb->decrypted values.
Correlate TLS offload initialization events with subsequent retransmit storms on the same 5-tuple.

Monitoring Recommendations

Track per-interface TX drop counters on NICs with TLS or PSP offload enabled.
Monitor netstat -s for elevated TCPRetransFail and SACK shift counters on affected hosts.
Alert on long-lived TCP connections that stop making forward progress after an offload state change.

How to Mitigate CVE-2026-98549

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the stable tree commits listed below.
Inventory hosts using TLS device offload or PSP offload, prioritizing systems with mlx5, nfp, or funeth NICs.
For systems that cannot be patched immediately, consider disabling TLS device offload until the kernel is updated.

Patch Information

The fix applies defense in depth at two locations. tcp_write_collapse_fence() now falls back to tcp_rtx_queue_tail(sk) when tcp_write_queue_tail(sk) is NULL. tcp_skb_can_collapse() now evaluates !skb_cmp_decrypted(to, from), matching the receive-side logic in tcp_skb_can_collapse_rx(). See the following upstream commits: Commit 08e835f, Commit 1ae7aee, Commit 7ba8750, Commit 9e2a2f9, and Commit fc6d80e.

Workarounds

Disable TLS device offload on affected interfaces using ethtool -K <iface> tls-hw-tx-offload off until patched kernels are deployed.
Avoid enabling PSP transmit association on connections where cleartext retransmission would be unacceptable.
Where feasible, reduce retransmit pressure by addressing upstream packet loss on paths carrying offloaded TLS traffic.

bash

# Disable TLS hardware TX offload as a temporary mitigation
ethtool -K eth0 tls-hw-tx-offload off
ethtool -K eth0 tls-hw-rx-offload off

# Verify current offload state
ethtool -k eth0 | grep tls