CVE-2026-64024

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix stale per-CPU tcp_tw_isn leak enabling ISN prediction<br /> <br /> Blamed commit moved the TIME_WAIT-derived ISN from the skb control<br /> block to a per-CPU variable, assuming the value would always be consumed<br /> by tcp_conn_request() for the same packet that wrote it. That assumption<br /> is violated by multiple drop paths between the producer<br /> (__this_cpu_write(tcp_tw_isn, isn) in tcp_v{4,6}_rcv()) and the consumer<br /> (tcp_conn_request()):<br /> <br /> - min_ttl / min_hopcount check<br /> - xfrm policy check<br /> - tcp_inbound_hash() MD5/AO mismatch<br /> - tcp_filter() eBPF/SO_ATTACH_FILTER drop<br /> - th-&gt;syn &amp;&amp; th-&gt;fin discard in tcp_rcv_state_process() TCP_LISTEN<br /> - psp_sk_rx_policy_check() in tcp_v{4,6}_do_rcv()<br /> - tcp_checksum_complete() in tcp_v{4,6}_do_rcv()<br /> - tcp_v{4,6}_cookie_check() returning NULL<br /> <br /> When a packet is dropped on any of these paths, tcp_tw_isn is left set.<br /> <br /> The next SYN processed on the same CPU then consumes the non zero value in<br /> tcp_conn_request(), receiving a potentially predictable ISN.<br /> <br /> This patch moves back tcp_tw_isn to skb-&gt;cb[], getting rid of the per-cpu<br /> variable.<br /> <br /> Note that tcp_v{4,6}_fill_cb() do not set it.<br /> <br /> Very litle impact on overall code size/complexity:<br /> <br /> $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new<br /> add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7)<br /> Function old new delta<br /> tcp_v6_rcv 3038 3042 +4<br /> tcp_v4_rcv 3035 3039 +4<br /> tcp_conn_request 2938 2923 -15<br /> Total: Before=24436060, After=24436053, chg -0.00%