CVE-2026-64045

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: tcp - use cached peer pointer in ovpn_tcp_close()<br /> <br /> ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data()<br /> under rcu_read_lock(), takes a reference on sock-&gt;peer, caches the peer<br /> pointer in a local, and drops the read lock. It then passes sock-&gt;peer<br /> (rather than the cached local) to ovpn_peer_del(), re-dereferencing the<br /> ovpn_socket after the RCU read section has ended.<br /> <br /> Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use<br /> after unlock" pattern but is protected by lock_sock() held across the<br /> function, ovpn_tcp_close() runs without the socket lock: inet_release()<br /> invokes sk_prot-&gt;close() without taking lock_sock first.<br /> <br /> ovpn_socket_release() can therefore complete its kref_put -&gt; detach -&gt;<br /> synchronize_rcu -&gt; kfree(sock) sequence concurrently, in the window<br /> after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences<br /> sock-&gt;peer. The synchronize_rcu() in ovpn_socket_release() protects<br /> readers that use the dereferenced pointer inside the RCU read section,<br /> not those that escape the pointer to a local and use it afterwards.<br /> <br /> A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp -<br /> don&amp;#39;t deref NULL sk_socket member after tcp_close()"): trigger a peer<br /> removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same<br /> moment userspace closes the TCP fd. That commit fixed the detach-side<br /> of the same race window; this one fixes the close-side at a different<br /> victim.<br /> <br /> Tighten the entry block to read sock-&gt;peer exactly once into the cached<br /> peer local, and route all subsequent uses (the hold check, the<br /> ovpn_peer_del() call, and the prot-&gt;close() invocation) through that<br /> local. sock-&gt;peer is only ever written once in ovpn_socket_new() under<br /> lock_sock(), before rcu_assign_sk_user_data() publishes the ovpn_socket,<br /> and is never reassigned afterwards - but the previous multi-read pattern<br /> made that invariant implicit rather than explicit. The same multi-read<br /> shape exists in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(),<br /> ovpn_tcp_data_ready() and ovpn_tcp_write_space(); those will be cleaned<br /> up via a dedicated helper in a follow-up net-next series.