The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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.
    (CVE-2026-98549)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2026-98549

critical Nessus Plugin ID 367052

Version 1.8