CVE-2026-64007

What it actually does

This is a Linux kernel use-after-free/stale-pointer flaw in the Netfilter SYNPROXY TCP timestamp handling path. When SYNPROXY adjusts TCP timestamp options, it may cache a TCP header pointer before calling skb_ensure_writable(). For cloned or non-linear socket buffers, that call can reallocate and free the original skb head, leaving the cached TCP header pointer stale. The subsequent checksum update may then write to freed kernel slab memory or update only a temporary stack copy, causing memory corruption or invalid outbound TCP checksums. Because the affected code is reachable from network packet processing and the CVSS vector indicates no privileges or user interaction are required, the worst-case technical impact is remote kernel memory corruption leading to denial of service and potentially code execution in kernel context, depending on exploitability on a given kernel build and allocator state.

Why it matters to the business

Systems using Linux Netfilter SYNPROXY for TCP connection protection may be exposed to remotely triggered kernel crashes or packet-processing instability. A successful attack could disrupt firewalls, load balancers, gateways, Kubernetes nodes, edge servers, or any Linux host enforcing SYNPROXY rules, causing service outages and possible compromise of the underlying host. The issue is recently published, not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the supplied data, but the high CVSS score and network-reachable kernel attack surface justify prompt patch planning, especially for internet-facing packet-filtering infrastructure.

How an attack unfolds

An attacker sends specially shaped TCP traffic that reaches a Linux Netfilter SYNPROXY rule and exercises TCP timestamp adjustment. The vulnerable path obtains a TCP header pointer, then makes the skb writable. If the packet buffer is cloned or non-linear, the kernel may expand or replace the skb head, freeing the memory referenced by the previously cached pointer. The SYNPROXY code then uses that stale pointer while patching the TCP checksum. Depending on memory layout and timing, this can corrupt freed slab memory, produce packets with bad checksums, or crash the kernel. Reliable exploitation for code execution would require controlling packet shape, triggering the vulnerable skb state, and manipulating kernel heap reuse; denial of service is the more straightforward expected outcome.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix for Netfilter SYNPROXY refreshing the TCP header pointer after skb_ensure_writable(). No exact fixed package versions were provided in the input, so use the relevant distribution kernel advisory, stable kernel release notes, or vendor errata for the affected platform. As a temporary mitigation, remove or disable Netfilter SYNPROXY rules where they are not required, including nftables synproxy expressions and iptables rules using the SYNPROXY target. If SYNPROXY is required for DDoS or SYN-flood protection, prioritize patching those hosts rather than disabling protection without an alternative control. Where feasible, restrict exposure of vulnerable packet-processing paths to trusted networks and ensure redundant edge systems are patched in a controlled rolling manner.

How to confirm the fix worked

Confirm that the running kernel version or vendor package changelog includes the fix described as refreshing/re-deriving the TCP header after skb_ensure_writable() in netfilter SYNPROXY. Verify that the patched kernel is actually booted, not merely installed, by checking the running kernel version after reboot. Review active firewall policy with nft list ruleset, iptables-save, and ip6tables-save to determine whether synproxy/SYNPROXY rules remain enabled. Validate that relevant kernel modules such as nf_synproxy_core, nft_synproxy, or xt_SYNPROXY are no longer present if SYNPROXY was intentionally disabled. For high-assurance validation, reproduce normal SYNPROXY-protected traffic in a staging environment and confirm there are no kernel warnings, crashes, or TCP checksum anomalies after the update.

Typical attack path

1. Identify a Linux system that processes inbound TCP traffic through Netfilter SYNPROXY rules, such as nftables synproxy or iptables xt_SYNPROXY.
2. Send crafted TCP packets with timestamp options that cause SYNPROXY timestamp adjustment to run.
3. Trigger conditions where the skb is cloned or non-linear so skb_ensure_writable() reallocates the skb head.
4. Cause the stale TCP header pointer to be used during checksum replacement after the original skb head has been freed.
5. Induce kernel memory corruption, packet checksum corruption, or a kernel crash; in a more advanced scenario, attempt to shape heap reuse for privileged code execution.

How to detect it

There is no reliable packet-level IOC that proves exploitation, and successful exploitation may only appear as a kernel crash, watchdog reboot, or unexplained packet-processing instability. Review kernel logs, persistent journal data, netconsole output, crash dumps, kdump vmcores, and hypervisor or cloud serial console logs for oops, panic, KASAN, KFENCE, slab corruption, or general protection fault messages involving Netfilter SYNPROXY functions. Look for crashes temporally correlated with inbound TCP SYN or SYN/ACK floods, unusual TCP timestamp-option traffic, or checksum-error spikes on systems with active synproxy/SYNPROXY rules. Network telemetry may show bursts of TCP packets with timestamp options directed at SYNPROXY-protected services, followed by host reboot or firewall failover. If crash dumps are available, inspect stack traces for nf_synproxy_core, ipv4_synproxy_hook, ipv6_synproxy_hook, synproxy_tstamp_adjust, skb_ensure_writable, pskb_expand_head, or inet_proto_csum_replace4. Also review firewall configuration history to determine whether exposed SYNPROXY rules were active during the suspected window.

• BUG: KASAN: use-after-free
• KASAN: use-after-free in synproxy_tstamp_adjust
• KASAN: slab-use-after-free
• BUG: KFENCE: use-after-free
• general protection fault
• kernel BUG at net/netfilter/nf_synproxy_core.c
• Oops:
• Kernel panic - not syncing
• nf_synproxy_core
• nft_synproxy
• xt_SYNPROXY
• synproxy_tstamp_adjust
• ipv4_synproxy_hook
• ipv6_synproxy_hook
• skb_ensure_writable
• pskb_expand_head
• inet_proto_csum_replace4
• TCP: bad checksum
• -j SYNPROXY
• synproxy

What your security team should do

• Inventory Linux systems that use Netfilter SYNPROXY, especially internet-facing firewalls, gateways, load balancers, reverse proxies, and container or virtualization hosts performing packet filtering.
• Prioritize patching systems with active nftables synproxy or iptables SYNPROXY rules, even though the vulnerability is not currently KEV-listed and EPSS is low.
• If immediate patching is not possible, temporarily disable SYNPROXY rules where operationally safe or move protection to a patched upstream device.
• Monitor kernel logs and crash telemetry for use-after-free, slab corruption, general protection faults, or oops traces involving Netfilter SYNPROXY code.
• After patch deployment, confirm the patched kernel is running and that no hosts remain booted into older vulnerable kernels.
• Add SOC detections for kernel crash artifacts referencing nf_synproxy_core, nft_synproxy, xt_SYNPROXY, skb_ensure_writable, pskb_expand_head, or inet_proto_csum_replace4.
• Track vendor kernel advisories and stable kernel backports because fixed versions vary by distribution and were not supplied in the input.