Linux Kernel EUVD-2026-45597

Exploitation requires that the attacker cause an inbound TCP packet to be dropped on one of the specific intermediate paths between the ISN producer in tcp_v{4,6}_rcv() and the consumer in tcp_conn_request() - namely a min_ttl/min_hopcount rejection, an xfrm policy drop, a tcp_inbound_hash() MD5/AO mismatch, a tcp_filter() eBPF/SO_ATTACH_FILTER drop, a th->syn && th->fin discard on a TCP_LISTEN socket, a psp_sk_rx_policy_check() failure, a tcp_checksum_complete() failure, or tcp_v{4,6}_cookie_check() returning NULL. That leaves tcp_tw_isn stale, and a following victim SYN must be processed on the same CPU to inherit the predictable ISN. Limiting factors: the value is merely predictable rather than attacker-chosen, success depends on same-CPU affinity and timing races (making real complexity high despite the CVSS AC:L), the kernel must be 6.10 through the fixed versions, and some of the drop paths themselves require non-default configuration such as active eBPF filters, TCP-MD5/AO, xfrm/IPsec policy, or PSP offload to be triggerable.

The signals conflict sharply. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H, score 9.4) rates this near-critical, but that appears inflated for the actual mechanism: exploitation is not a simple low-complexity network hit. Realistically an attacker must induce a packet drop on a specific intermediate path, land it on the same CPU as a subsequent victim SYN, and then leverage a merely predictable (not attacker-chosen) ISN for spoofing - closer to high attack complexity than AC:L, and the A:H (availability) impact is not well supported by the description, which is an ISN-prediction/integrity issue, not a crash or DoS. Corroborating this lower real-world risk: EPSS is 0.17% (6th percentile) and the tag is 'Information Disclosure,' not remote code execution. There is no KEV listing and no public exploit identified at time of analysis. Net assessment: this is a legitimate integrity-weakening kernel bug worth patching in normal cycles, but the 9.4 headline overstates practical urgency - treat it as medium priority rather than an emergency, and note the CVSS availability/complexity metrics are questionable versus the described behavior.

An off-path attacker who can reliably trigger one of the kernel's SYN drop paths (for example, by sending a packet that fails an eBPF/socket filter or checksum, or a SYN+FIN to a listening socket) causes the stale tcp_tw_isn to persist on that CPU. A legitimate client's subsequent SYN handled on the same CPU is then assigned a predictable ISN, which the attacker can use to spoof or inject segments into the resulting connection. No public exploit is identified at time of analysis, and the required timing/CPU-affinity alignment makes reliable exploitation difficult.