Cloudanix VulnDB

CVE-2026-98549

None

CVSS

—

EPSS

0.1%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's TCP retransmission handling can let encrypted data be sent unencrypted or cause connections to freeze when certain network hardware offload features are active.

Exploitation
Other
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A fence intended to block skb collapsing across device-encryption boundaries in the TCP retransmit queue is bypassed when the write queue is empty; subsequent retransmit or SACK-shift operations can merge post-switch skbs into pre-switch skbs, causing decrypted=0 to be inherited (cleartext leak for PSP) or straddling the TLS offload marker (stall for software fallback and mlx5/nfp/funeth drivers).

Why it matters to the business

Organizations running affected Linux kernels on systems using PSP encryption or TLS device offload may experience data exposure on retransmission or connection stalls that require manual intervention, though the low EPSS score and lack of KEV listing indicate limited real-world exploitation risk five days after disclosure.

How an attack unfolds

An attacker triggers TCP retransmission or SACK processing after a switch to device encryption has occurred; because the fence did not protect skbs already in the rtx queue, collapse merges an skb carrying post-switch data into an earlier skb, violating the encryption boundary and either sending data in cleartext or causing repeated drops that stall the connection.

How to fix it

Apply the upstream fix that falls back to tcp_rtx_queue_tail when the write queue is empty and adds an skb_cmp_decrypted check in tcp_skb_can_collapse; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Confirm the presence of the two defensive changes (tcp_write_collapse_fence fallback and skb_cmp_decrypted guard) in the running kernel source or binary; exercise retransmit paths under PSP/TLS offload conditions and verify that merging no longer occurs across encryption boundaries.

Typical attack path

  1. Establish a TCP connection that later switches to PSP or TLS device offload.
  2. Force or wait for conditions that place unacknowledged data in the rtx queue.
  3. Trigger retransmission or SACK shifting that invokes tcp_retrans_try_collapse or tcp_shift_skb_data.
  4. Observe either cleartext transmission of post-switch data or repeated skb drops leading to connection stall.

How to detect it

Search kernel and network logs for repeated skb collapse events during retransmission under PSP or TLS offload, unexpected cleartext packets on encrypted flows, or stalled connections that rebuild the same skb on every retransmit attempt.

What your security team should do

  • Prioritize kernel updates on hosts using PSP encryption or TLS hardware offload.
  • Monitor EPSS trend and any future KEV additions given the five-day disclosure window.
  • Review network configurations to reduce reliance on retransmission-heavy paths until patches are applied.

The record

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: 1. Fall back to tcp_rtx_queue_tail(sk) in tcp_write_collapse_fence() when tcp_write_queue_tail(sk) is NULL. 2. 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.

Affected packages

Ecosystem Package Introduced Fixed