In the Linux kernel, the following vulnerability has been resolved: ovpn: tcp - use cached peer pointer in ovpn_tcp_close() ovpn_tcp_close() loads… (CVE-2026-64045)
In the Linux kernel, the following vulnerability has been resolved: ovpn: tcp - use cached peer pointer in ovpn_tcp_close() ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data() under rcu_read_lock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpn_peer_del(), re-dereferencing the ovpn_socket after the RCU read section has ended. Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use after unlock" pattern but is protected by lock_sock() held across the function, ovpn_tcp_close() runs without the socket lock: inet_release() invokes sk_prot->close() without taking lock_sock first. ovpn_socket_release() can therefore complete its kref_put -> detach -> synchronize_rcu -> kfree(sock) sequence concurrently, in the window after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences sock->peer. The synchronize_rcu() in ovpn_socket_release() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards. A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp - don't deref NULL sk_socket member after tcp_close()"): trigger a peer removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim. Tighten the entry block to read sock->peer exactly once into the cached peer local, and route all subsequent uses (the hold check, the ovpn_peer_del() call, and the prot->close() invocation) through that local. sock->peer is only ever written once in ovpn_socket_new() under lock_sock(), before rcu_assign_sk_user_data() publishes the ovpn_socket, and is never reassigned afterwards - but the previous multi-read pattern made that invariant implicit rather than explicit. The same multi-read shape exists in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space(); those will be cleaned up via a dedicated helper in a follow-up net-next series.
AI Analysis
Technical Summary
The vulnerability in the Linux kernel's OpenVPN TCP code involves ovpn_tcp_close() loading the ovpn_socket peer pointer under an RCU read lock, caching it locally, then dropping the lock and subsequently using the original sock->peer pointer instead of the cached local. Because ovpn_tcp_close() does not hold the socket lock, concurrent execution of ovpn_socket_release() can free the peer object after the RCU lock is dropped but before the pointer is dereferenced, causing a use-after-free condition. The patch modifies ovpn_tcp_close() to read sock->peer exactly once into a local variable and use only that cached pointer thereafter, eliminating the race window. This vulnerability is related to a previous fix addressing the detach side of the race but affects the close side.
Potential Impact
The vulnerability can cause use-after-free memory access during TCP socket close operations in OpenVPN over the Linux kernel, potentially leading to kernel crashes or undefined behavior. No known exploits in the wild have been reported. The impact is limited to kernel stability and memory safety within the affected OpenVPN TCP code path.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to address this vulnerability by changing ovpn_tcp_close() to use a cached peer pointer consistently. Users should update to the fixed kernel version once available. Since this is a kernel-level issue, applying the official kernel patch or upgrading to a kernel version containing this fix is the recommended mitigation. Patch status is not explicitly confirmed in the provided data; check the vendor advisory or Linux kernel mailing lists for the specific fixed version and apply updates accordingly.
In the Linux kernel, the following vulnerability has been resolved: ovpn: tcp - use cached peer pointer in ovpn_tcp_close() ovpn_tcp_close() loads… (CVE-2026-64045)
Description
In the Linux kernel, the following vulnerability has been resolved: ovpn: tcp - use cached peer pointer in ovpn_tcp_close() ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data() under rcu_read_lock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpn_peer_del(), re-dereferencing the ovpn_socket after the RCU read section has ended. Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use after unlock" pattern but is protected by lock_sock() held across the function, ovpn_tcp_close() runs without the socket lock: inet_release() invokes sk_prot->close() without taking lock_sock first. ovpn_socket_release() can therefore complete its kref_put -> detach -> synchronize_rcu -> kfree(sock) sequence concurrently, in the window after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences sock->peer. The synchronize_rcu() in ovpn_socket_release() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards. A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp - don't deref NULL sk_socket member after tcp_close()"): trigger a peer removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim. Tighten the entry block to read sock->peer exactly once into the cached peer local, and route all subsequent uses (the hold check, the ovpn_peer_del() call, and the prot->close() invocation) through that local. sock->peer is only ever written once in ovpn_socket_new() under lock_sock(), before rcu_assign_sk_user_data() publishes the ovpn_socket, and is never reassigned afterwards - but the previous multi-read pattern made that invariant implicit rather than explicit. The same multi-read shape exists in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space(); those will be cleaned up via a dedicated helper in a follow-up net-next series.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in the Linux kernel's OpenVPN TCP code involves ovpn_tcp_close() loading the ovpn_socket peer pointer under an RCU read lock, caching it locally, then dropping the lock and subsequently using the original sock->peer pointer instead of the cached local. Because ovpn_tcp_close() does not hold the socket lock, concurrent execution of ovpn_socket_release() can free the peer object after the RCU lock is dropped but before the pointer is dereferenced, causing a use-after-free condition. The patch modifies ovpn_tcp_close() to read sock->peer exactly once into a local variable and use only that cached pointer thereafter, eliminating the race window. This vulnerability is related to a previous fix addressing the detach side of the race but affects the close side.
Potential Impact
The vulnerability can cause use-after-free memory access during TCP socket close operations in OpenVPN over the Linux kernel, potentially leading to kernel crashes or undefined behavior. No known exploits in the wild have been reported. The impact is limited to kernel stability and memory safety within the affected OpenVPN TCP code path.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to address this vulnerability by changing ovpn_tcp_close() to use a cached peer pointer consistently. Users should update to the fixed kernel version once available. Since this is a kernel-level issue, applying the official kernel patch or upgrading to a kernel version containing this fix is the recommended mitigation. Patch status is not explicitly confirmed in the provided data; check the vendor advisory or Linux kernel mailing lists for the specific fixed version and apply updates accordingly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-xr5j-v9xh-823c
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64045"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a92a4a8d598912c86f
Added to database: 07/19/2026, 19:38:17 UTC
Last enriched: 07/19/2026, 19:53:53 UTC
Last updated: 07/20/2026, 19:41:22 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.