CVE-2026-64007

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: synproxy: refresh tcphdr after skb_ensure_writable<br /> <br /> synproxy_tstamp_adjust() rewrites the TCP timestamp option in place<br /> and then patches the TCP checksum via inet_proto_csum_replace4() on<br /> the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and<br /> ipv6_synproxy_hook() obtain that pointer with skb_header_pointer()<br /> before calling in, so it may either alias skb-&gt;head directly or<br /> point at the caller&amp;#39;s on-stack _tcph buffer.<br /> <br /> Between obtaining the pointer and using it, the function calls<br /> skb_ensure_writable(skb, optend), which on a cloned or non-linear<br /> skb invokes pskb_expand_head() and frees the old skb-&gt;head. After<br /> that point the cached th is stale:<br /> <br /> caller (ipv[46]_synproxy_hook)<br /> th = skb_header_pointer(skb, ..., &amp;_tcph)<br /> synproxy_tstamp_adjust(skb, protoff, th, ...)<br /> skb_ensure_writable(skb, optend)<br /> pskb_expand_head() /* kfree(old skb-&gt;head) */<br /> ...<br /> inet_proto_csum_replace4(&amp;th-&gt;check, ...)<br /> /* writes into freed head, or<br /> into the caller&amp;#39;s stack copy<br /> leaving the on-wire checksum<br /> stale */<br /> <br /> The option bytes are written through skb-&gt;data and are fine; only<br /> the checksum update goes through th and so lands in the wrong<br /> place. The result is either a write into freed slab memory or a<br /> packet leaving with a checksum that does not match its payload.<br /> <br /> Fix by re-deriving th from skb-&gt;data + protoff immediately after<br /> skb_ensure_writable() succeeds, so the subsequent checksum update<br /> targets the linear, writable header.