Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessTarget TLS/PSP offloaded TCP connection
-
DeliveryInduce packet loss or SACK event
-
ExploitKernel collapses skbs across encryption boundary
-
ExecutionMerged skb bypasses device encryption
-
ImpactPlaintext data leaked or connection stalls
Vulnerability Assessment
| Exploitation Conditions | The affected system must be configured with device-offloaded encryption: either PSP socket TX encryption (psp_sock_assoc_set_tx) or kernel TLS device offload (tls_set_device_offload) on a supporting NIC (mlx5, nfp, or funeth). The fence that normally prevents cross-boundary collapse must have been a no-op - i.e. sk->sk_write_queue was empty at the moment of the switch so earlier unacknowledged skbs remained in sk->tcp_rtx_queue with eor=0. Exploitation then requires a subsequent retransmit or SACK shift to invoke the collapse path. Limiting factors: this is a non-default configuration (device encryption offload is not enabled on typical hosts), and the triggering retransmit/SACK event is driven by network conditions the attacker cannot directly command, which substantially narrows realistic exploitability below what the AV:N/AC:L CVSS vector suggests. |
| Impact | The signals conflict sharply and should be reconciled before prioritization. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, base 9.1) models a trivially exploitable, unauthenticated, network-reachable flaw, but the description contradicts AC:L: the bug only manifests when device-offloaded encryption (PSP or kernel TLS device offload) is configured AND a subsequent retransmit or SACK shift causes tcp_retrans_try_collapse()/tcp_shift_skb_data() to merge an skb across the encryption boundary - a condition the attacker does not directly control. EPSS is 0.13% (2nd percentile), consistent with a latent, hard-to-weaponize kernel bug rather than mass exploitation; there is no CISA KEV listing and no public exploit identified at time of analysis. The vuln.today Decision label is act_now, driven by a patched upstream kernel flaw with real impact (plaintext leakage or connection stall), so this should be treated as a prompt patching item - but the low EPSS, absent KEV, and non-default configuration prerequisite indicate the realistic exposure is narrow (only PSP/TLS-device-offload deployments on supported NICs), not a widespread drive-by threat. Net: genuinely serious for the specific populations that run device encryption offload, lower practical urgency for the majority of Linux systems that do not. Note the AC:L/PR:N vs. description mismatch - verify the real trigger conditions against the vendor commit before relying on the 9.1 score. |
| Exploit ScenarioDerived | On a Linux host using PSP socket encryption or kernel TLS device offload, data queued after the switch to device encryption sits unacknowledged in the retransmit queue with eor=0. When packet loss triggers a retransmit or a SACK shift, the kernel collapses a post-switch skb into a pre-switch one: for PSP the merged data is retransmitted in cleartext (information disclosure), and for TLS device offload the driver cannot handle the straddling skb and drops it on every retransmit, stalling the connection (denial of service). No public PoC or exploit reference is present in the supplied data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Linux kernel TCP retransmission handling can leak plaintext data on hosts that use device-offloaded encryption: an skb queued after a switch to PSP socket TX encryption or kTLS device offload may be collapsed into an earlier, not-yet-acknowledged skb, so bytes written after the switch are retransmitted in cleartext (C:H/I:N/A:H, CVSS 9.1 base, assessed vector AC:H because the merge only happens in specific offload configurations after a no-op fence is followed by a retransmit or SACK shift). On the kTLS device-offload path the merged skb straddles the TLS start marker, which the software fallback and the mlx5, nfp and funeth drivers cannot handle and drop, so every retransmit rebuilds the same skb and the connection stalls. Unauthenticated remote attackers are the relevant threat per the PR:N/AV:N vector, but no CISA KEV entry or public exploit code is associated with this CVE and EPSS is only 0.13% (2nd percentile), while the internal decision label is act_now - the signals conflict sharply and should be reconciled before prioritization, starting with whether the affected offload feature is enabled at all.
RemediationAI
Vendor-released patch: 6.12.112, 6.18.55, 7.2.9 and 7.3-rc5, delivered through the stable commits referenced in the advisory (https://git.kernel.org/stable/c/fc6d80eb504458d6416b75a94188b268c95c6533, https://git.kernel.org/stable/c/1ae7aee395245874d797890380d9192bd858fb7e, https://git.kernel.org/stable/c/7ba87509c54cd519e7ed362e0c85e8431f066a18, https://git.kernel.org/stable/c/08e835f5ec6e261c79d8c39f8618b3af29e3b0da and https://git.kernel.org/stable/c/9e2a2f98e8c0197108c6d97a1fa43bfd89071c30); because EUVD places the affected range at Linux 4.18 and the supplied list covers only these branches, confirm with the vendor or your distribution whether a backport exists for any other longterm or downstream kernel you run. Remediation priority should follow the internal act_now label and the reachability of the precondition: inventory hosts using PSP TX device encryption or kTLS device offload on mlx5, nfp or funeth hardware first, since those are the only configurations where the collapse can expose cleartext data or stall a connection. Where an immediate kernel update is not possible, the exposure is removed by not enabling device-offloaded encryption - keeping PSP TX association off, or running kTLS without device offload so encryption stays in software - at the cost of losing hardware crypto acceleration and shifting the load onto host CPUs; the supplied data does not describe any other vendor-endorsed workaround.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw sits in the TCP transmit bookkeeping that decides when two adjacent skbs may be merged. tcp_write_collapse_fence() marks the tail of sk->sk_write_queue with TCP_SKB_CB(skb)->eor = 1 so that data queued after a switch to device encryption is never folded into earlier, pre-switch data; the fence silently does nothing if all earlier data has already left the write queue, because tcp_write_queue_tail(sk) is NULL and the not-yet-acknowledged skbs are waiting in sk->tcp_rtx_queue with eor still 0. A later retransmit or SACK-driven shift through tcp_retrans_try_collapse() or tcp_shift_skb_data() can then merge a post-switch skb into a pre-switch one. For PSP, only skbs with skb->decrypted set are encrypted by the device, and the merged skb inherits decrypted = 0 from the earlier skb, so post-association data is retransmitted in the clear. For kTLS device offload the merged skb crosses the marker set in tls_set_device_offload(), and neither the in-kernel fallback (fill_sg_in() returns -EINVAL) nor the mlx5, nfp and funeth drivers can process such an skb, causing repeated drops and a stalled connection. The upstream fix is defense in depth: tcp_write_collapse_fence() falls back to tcp_rtx_queue_tail(sk) when the write queue is empty, and tcp_skb_can_collapse() now also checks !skb_cmp_decrypted(to, from), mirroring tcp_skb_can_collapse_rx() on the receive side and matching the existing DEBUG_NET_WARN_ON_ONCE() in skb_shift(). No CWE identifier is assigned in the supplied data; CPE records identify the generic linux:linux product, and EUVD lists Linux 4.18 among the affected version data.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Requires non-default device-offload encryption plus an attacker-uncontrolled retransmit/SACK event, so AC:H; no attacker privilege or auth, so PR:N; impact is plaintext leakage (C:H) or connection stall (A:H).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
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.
Executive ViewAI
A critical Linux kernel vulnerability (CVE-2026-98549) can expose plaintext data on systems using device-offloaded encryption, potentially leaking sensitive information or causing connection stalls. Leadership should prioritize patching because the flaw affects confidentiality and availability of encrypted communications, though no active exploitation has been observed.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-103594
GHSA-p59j-fj4g-255h
NVD
CVE.org
EPSS
Exploit-DB