CVE-2025-39852

What it actually does

Memory leak of newly allocated TCP socket structures (sk_prot_alloc / sk_clone_lock) in tcp_v6_syn_recv_sock when tcp_ao_copy_all_matching fails; the error path omits inet_csk_prepare_forced_close and tcp_done, leaving the object unreferenced.

Why it matters to the business

Systems accepting many IPv6 TCP connections that use TCP Authentication Option can gradually exhaust kernel memory, degrading performance or triggering OOM kills on long-lived servers.

How an attack unfolds

An attacker initiates IPv6 TCP handshakes that trigger the TCP-AO failure path in tcp_v6_syn_recv_sock; repeated failures accumulate leaked socket objects until memory pressure causes denial of service.

How to fix it

Upgrade the Linux kernel to a version containing commit 46d33c878fc0b3d7570366b2c9912395b3f4e701 or later; apply the same error-handling pattern used in tcp_v4_syn_recv_sock (put_and_exit label) to both IPv4 and IPv6 paths.

How to confirm the fix worked

Confirm the presence of commit 46d33c878fc0b3d7570366b2c9912395b3f4e701 in the running kernel source or binary; run kmemleak or slabinfo before/after synthetic IPv6 TCP-AO failure tests to verify leak elimination.

Typical attack path

1. Send crafted IPv6 SYN packets that cause tcp_ao_copy_all_matching to fail inside tcp_v6_syn_recv_sock
2. Trigger the early return that bypasses forced-close cleanup
3. Repeat to accumulate unreferenced socket allocations
4. Monitor for kernel memory exhaustion or OOM events

How to detect it

Inspect kernel logs and kmemleak reports for unreferenced sk_buff or sock objects allocated from tcp_v6_syn_recv_sock or tcp_create_openreq_child during IPv6 SYN processing; correlate with TCP-AO enabled listeners.

What your security team should do

• Prioritize kernel upgrade on all systems that enable TCP-AO over IPv6
• Monitor kernel memory usage and OOM logs on IPv6-facing servers
• Apply the patch or backport the error-handling fix if immediate reboot is not feasible