CVE-2026-64045: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64045 Overview

CVE-2026-64045 is a use-after-free race condition in the Linux kernel's OpenVPN (ovpn) TCP transport code. The flaw resides in the ovpn_tcp_close() function, which dereferences sock->peer after the RCU read-side critical section has ended. Because inet_release() invokes sk_prot->close() without holding lock_sock(), ovpn_socket_release() can concurrently execute its kref_put -> detach -> synchronize_rcu -> kfree(sock) sequence. An attacker who can trigger peer removal (via keepalive expiration or an OVPN_CMD_DEL_PEER netlink command) at the moment userspace closes the TCP file descriptor can race the free, corrupting kernel memory.

Critical Impact
Local attackers can exploit this race window in the ovpn TCP close path to cause kernel memory corruption, leading to privilege escalation or denial of service.

Affected Products

Linux kernel versions containing the ovpn TCP transport module
Distributions shipping the vulnerable ovpn socket implementation prior to the referenced fix commits
Systems using OpenVPN Data Channel Offload (DCO) with TCP transport

Discovery Timeline

2026-07-19 - CVE-2026-64045 published to the National Vulnerability Database
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64045

Vulnerability Analysis

The vulnerability is a Use-After-Free ([CWE-416]) triggered by a race between socket close and peer detach. ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data() under rcu_read_lock(), takes a reference on sock->peer, and then drops the RCU read lock. It subsequently passes sock->peer (not the cached local) to ovpn_peer_del(), re-dereferencing the ovpn_socket after the RCU section has ended.

Unlike ovpn_tcp_sendmsg(), which uses the same load-under-RCU pattern but is protected by lock_sock() held across the function, ovpn_tcp_close() runs without the socket lock. This is because inet_release() invokes sk_prot->close() without first acquiring lock_sock. The synchronize_rcu() in ovpn_socket_release() only 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.

Root Cause

The root cause is an incorrect assumption that sock->peer remains valid after rcu_read_unlock(). While sock->peer is written only once in ovpn_socket_new() under lock_sock() before rcu_assign_sk_user_data() publishes the ovpn_socket, the multi-read pattern in ovpn_tcp_close() made that invariant implicit. The concurrent ovpn_socket_release() free path can therefore complete between the RCU unlock and the subsequent dereference.

Attack Vector

A local attacker with the ability to control an OpenVPN peer triggers the race by removing a peer (through keepalive expiration or the netlink OVPN_CMD_DEL_PEER command) while userspace simultaneously closes the associated TCP file descriptor. This pattern mirrors the reproducer used in commit 94560267d6c4, which fixed the detach side of the same race window. The current fix, introduced in commits 775d8d7, d3ef441, and e5460eb, tightens the entry block to read sock->peer exactly once into a cached local and routes all subsequent uses through that local.

Detection Methods for CVE-2026-64045

Indicators of Compromise

Unexpected kernel oops or panic messages referencing ovpn_tcp_close, ovpn_peer_del, or ovpn_socket_release in dmesg output
KASAN (Kernel Address Sanitizer) reports flagging use-after-free access in the ovpn module
Abnormal kernel memory corruption crashes correlated with OpenVPN TCP peer disconnection events

Detection Strategies

Enable KASAN on test kernels to surface the use-after-free during fuzzing of the ovpn netlink and socket close paths
Monitor kernel logs for stack traces including ovpn_tcp_close following OVPN_CMD_DEL_PEER netlink operations
Audit installed kernel package versions against distribution advisories referencing the fix commits 775d8d7ad02a, d3ef441907fc, and e5460eb7238c

Monitoring Recommendations

Track netlink activity issuing OVPN_CMD_DEL_PEER commands correlated with TCP socket close syscalls on the same peer
Alert on repeated kernel crashes on hosts running OpenVPN DCO with TCP transport
Ingest dmesg and /var/log/kern.log into a centralized log store for retrospective analysis of race-condition crashes

How to Mitigate CVE-2026-64045

Immediate Actions Required

Apply the upstream kernel patches referenced by commits 775d8d7ad02a, d3ef441907fc, and e5460eb7238c to remove the multi-read pattern in ovpn_tcp_close()
Update to a distribution kernel that incorporates the fix once available from your vendor
Restrict local access to hosts running OpenVPN DCO with TCP transport until patched

Patch Information

The fix modifies ovpn_tcp_close() to read sock->peer exactly once into a cached local pointer within the RCU read section. All subsequent uses — the hold check, the ovpn_peer_del() call, and the prot->close() invocation — are routed through the cached local rather than re-dereferencing sock->peer after rcu_read_unlock(). See the Kernel Git Commit #775d8d7, Kernel Git Commit #d3ef441, and Kernel Git Commit #e5460eb for the exact code changes.

Workarounds

Switch OpenVPN DCO transport from TCP to UDP where operationally feasible, as the vulnerable code path is specific to ovpn_tcp_close()
Limit which local users can invoke OVPN_CMD_DEL_PEER by tightening CAP_NET_ADMIN grants and namespace isolation
Disable or unload the ovpn kernel module on hosts that do not require OpenVPN DCO functionality

bash

# Verify running kernel and ovpn module status
uname -r
lsmod | grep ovpn

# Unload the ovpn module if not required
sudo modprobe -r ovpn

# Blacklist the module to prevent auto-load
echo 'blacklist ovpn' | sudo tee /etc/modprobe.d/blacklist-ovpn.conf