CVE-2026-64459

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: restore RCU grace period in tcp_ao_destroy_sock<br /> <br /> Commit 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU")<br /> removed the call_rcu() callback from tcp_ao_destroy_sock(), arguing that<br /> "the destruction of info/keys is delayed until the socket destructor"<br /> and therefore "no one can discover it anymore".<br /> <br /> That argument does not hold for the call site in tcp_connect()<br /> (net/ipv4/tcp_output.c:4327-4332). At that point the socket is in<br /> TCP_SYN_SENT, has already been inserted into the inet ehash by<br /> inet_hash_connect() in tcp_v4_connect(), and is therefore very much<br /> discoverable: any softirq running tcp_v4_rcv() on another CPU can take<br /> the socket out of the ehash, walk into tcp_inbound_hash(), and load<br /> tp-&gt;ao_info via implicit RCU before bh_lock_sock_nested() is taken on<br /> the destroying CPU.<br /> <br /> The reader path then enters __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208)<br /> which re-loads tp-&gt;ao_info via rcu_dereference_check(); the re-load can<br /> still observe the (about-to-be-freed) pointer because there is no<br /> synchronize_rcu() between rcu_assign_pointer(tp-&gt;ao_info, NULL) and<br /> tcp_ao_info_free() in tcp_ao_destroy_sock(). The captured pointer is<br /> then walked at line 223:<br /> <br /> hlist_for_each_entry_rcu(key, &amp;ao-&gt;head, node, ...)<br /> <br /> The writer&amp;#39;s synchronous kfree() is free to complete between the line<br /> 218 re-fetch and the line 223 hlist iteration. The slab is reused<br /> (or simply LIST_POISON1-stamped if not yet reused) and the iteration<br /> walks attacker-controlled or poison memory in softirq context.<br /> <br /> Reproducer (no debug shim, stock x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM):<br /> an unprivileged uid=1000 process inside CLONE_NEWUSER|CLONE_NEWNET<br /> installs TCP_MD5SIG + TCP_AO_ADD_KEY on a TCP socket, sprays forged<br /> TCP-AO segments toward its eventual 4-tuple via raw sockets, then<br /> calls connect(). The md5-wins reconciliation in tcp_connect() fires<br /> tcp_ao_destroy_sock(); the softirq backlog reader on the loopback<br /> NAPI path crashes on the freed ao-&gt;head.first walk:<br /> <br /> Oops: general protection fault, probably for non-canonical<br /> address 0xfbd59c000000002f<br /> KASAN: maybe wild-memory-access in range<br /> [0xdead000000000178-0xdead00000000017f]<br /> CPU: 0 UID: 1000 PID: 100 Comm: repro_userns<br /> RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0<br /> Call Trace: <br /> __tcp_ao_do_lookup+0x107/0x1c0<br /> tcp_ao_inbound_lookup.constprop.0+0x12a/0x200<br /> tcp_inbound_ao_hash+0x5ea/0x1520<br /> tcp_inbound_hash+0x7ce/0x1240<br /> tcp_v4_rcv+0x1e7a/0x3e10<br /> ...<br /> <br /> Restore the RCU grace period: re-add struct rcu_head to tcp_ao_info<br /> and replace the synchronous tcp_ao_info_free() with a call_rcu()<br /> callback. Readers that captured tp-&gt;ao_info before rcu_assign_pointer<br /> NULLed it now see the object remain valid until rcu_read_unlock().<br /> With the patch applied the reproducer runs cleanly for 2000 iterations<br /> on the same kernel build.