CVE-2026-64045
Received Received - Intake

Use-After-Free in OpenVPN Kernel Module

Vulnerability report for CVE-2026-64045, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-07-19

Last updated on: 2026-07-19

Assigner: kernel.org

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 Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-07-19
Last Modified
2026-07-19
Generated
2026-07-20
AI Q&A
2026-07-19
EPSS Evaluated
N/A
NVD
EUVD

Affected Vendors & Products

Currently, no data is known.

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves a race condition in the OpenVPN TCP implementation. The issue occurs in ovpn_tcp_close() where a pointer to a peer is loaded under an RCU read lock, cached locally, and then used after the lock is dropped. Since the socket lock is not held during this process, another thread could free the socket and peer data before ovpn_tcp_close() dereferences the cached pointer, leading to a use-after-free scenario.

Detection Guidance

This vulnerability is specific to the Linux kernel's OpenVPN implementation and requires kernel-level detection. There are no standard network commands to detect it directly. Monitoring kernel logs for crashes or errors related to OpenVPN TCP connections may indicate exploitation. Check for kernel oops messages or system crashes during high-load OpenVPN TCP sessions.

Impact Analysis

This vulnerability could allow an attacker to cause a denial of service or potentially execute arbitrary code with kernel privileges. It may lead to system crashes, data corruption, or unauthorized access if exploited successfully.

Compliance Impact

This vulnerability does not directly affect compliance with standards like GDPR or HIPAA as it is a Linux kernel issue related to a race condition in OpenVPN's TCP socket handling. Compliance impacts would depend on how the affected system is used in a regulated environment.

Mitigation Strategies

Apply the latest kernel update that includes the fix for CVE-2026-64045. If immediate patching is not possible, consider disabling OpenVPN TCP mode temporarily or switching to UDP mode until the patch is applied. Monitor system stability and OpenVPN logs for signs of exploitation.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-64045. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart