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

CVE-2026-64044 Overview

CVE-2026-64044 is a use-after-free vulnerability in the Linux kernel's ovpn (OpenVPN in-kernel data channel offload) module. The flaw resides in the ovpn_nl_peer_new_doit() error path, which calls ovpn_peer_release() directly instead of ovpn_peer_put(), bypassing the kernel reference counter (kref). For TCP peers, ovpn_tcp_socket_attach() publishes the socket via rcu_assign_sk_user_data() before the error check, allowing concurrent userspace syscalls and the strparser-driven receive path to hold live references to the peer. If the netlink command fails, the peer is freed while another thread still references it, corrupting kernel memory.

Critical Impact
A local, low-privileged user can trigger use-after-free memory corruption in the Linux kernel, enabling potential local privilege escalation and full compromise of confidentiality, integrity, and availability.

Affected Products

Linux kernel versions containing the ovpn module with the vulnerable ovpn_nl_peer_new_doit() implementation
Distributions shipping kernels prior to the fix commits 0c3ef71, 1fef661, and 82988349
Systems using the in-kernel OpenVPN data channel offload over TCP transport

Discovery Timeline

2026-07-19 - CVE-2026-64044 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64044

Vulnerability Analysis

The vulnerability stems from an incorrect assumption in the ovpn_nl_peer_new_doit() error-handling path. The original code comment stated that a newly created peer "was not yet hashed, thus it is not used in any context," justifying a direct call to ovpn_peer_release(). This assumption holds only for UDP peers, where the ovpn_socket union does not reference the peer and UDP encap_recv looks up peers via hashtables that have not yet been populated.

For TCP peers, the assumption breaks. ovpn_socket_new() sets ovpn_sock->peer, and ovpn_tcp_socket_attach() publishes the socket via rcu_assign_sk_user_data(). From that moment, userspace recvmsg, sendmsg, close, and poll operations on the file descriptor, along with the strparser-driven ovpn_tcp_rcv() path, can reach the peer through sk_user_data -> ovpn_sock->peer and increment its refcount via ovpn_peer_hold().

Root Cause

The root cause is a reference-counting bypass [CWE-416]. ovpn_tcp_socket_wait_finish(), invoked inside ovpn_socket_release(), drains strparser and the transmit work queue but does not synchronize with userspace syscall callers already holding a peer reference. When ovpn_nl_peer_modify() or ovpn_peer_add() returns an error while an ovpn_tcp_recvmsg() caller is blocked in __skb_recv_datagram() on peer->tcp.user_queue, the direct ovpn_peer_release() destroys the peer while the concurrent caller retains a live reference.

Attack Vector

A local user with permission to issue ovpn netlink commands can race a CMD_NEW_PEER operation against a concurrent syscall on the TCP socket. By forcing the netlink path to fail after ovpn_tcp_socket_attach() publishes the socket, the attacker causes the peer to be freed prematurely. The subsequent ovpn_peer_put() from the blocked syscall operates on freed memory, producing a classic use-after-free condition exploitable for kernel memory corruption and local privilege escalation.

The fix replaces the direct destructor call with ovpn_peer_put(), allowing the kref to defer destruction until the last reference is dropped. See the kernel fix commit 0c3ef71 for the patch details.

Detection Methods for CVE-2026-64044

Indicators of Compromise

Kernel oops or panic messages referencing ovpn_peer_release, ovpn_peer_put, or ovpn_tcp_recvmsg in dmesg or /var/log/kern.log
KASAN (Kernel Address Sanitizer) reports flagging use-after-free in the ovpn module
Unexpected process crashes or privilege changes on hosts running the in-kernel OpenVPN data channel

Detection Strategies

Monitor kernel logs for stack traces containing ovpn_nl_peer_new_doit, ovpn_socket_release, or references to freed peer structures
Audit netlink command usage against the ovpn family for repeated CMD_NEW_PEER failures, which may indicate a race exploitation attempt
Deploy eBPF-based kernel behavior monitoring to detect anomalous slab reuse patterns in the ovpn peer allocation cache

Monitoring Recommendations

Enable kernel lockdown, KASAN, or KFENCE in test environments to surface latent memory corruption in the ovpn code path
Track running kernel versions across the fleet and correlate against fix commits 0c3ef71, 1fef661, and 82988349
Alert on unprivileged user processes issuing high-frequency ovpn netlink operations combined with concurrent TCP socket activity

How to Mitigate CVE-2026-64044

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in commits 0c3ef71, 1fef661, and 82988349 and reboot affected hosts
Restrict access to the ovpn netlink family to trusted administrators only, using capability controls (CAP_NET_ADMIN) and namespace isolation
Disable or unload the ovpn kernel module on systems that do not require the in-kernel OpenVPN data channel offload

Patch Information

The fix replaces the direct ovpn_peer_release() call in the ovpn_nl_peer_new_doit() error path with ovpn_peer_put(), ensuring the kref correctly defers destruction until the last reference is dropped. ovpn_peer_release() is made static and its declaration removed from peer.h. Consult the kernel.org stable commit 1fef661 and commit 82988349 for the backported fixes to stable kernel branches.

Workarounds

Switch OpenVPN deployments from TCP transport to UDP, which is not affected by the TCP-specific socket publication race
Prevent unprivileged users from opening ovpn netlink sockets by tightening seccomp and Linux capabilities policies
Use modprobe blacklisting to disable the ovpn module until patched kernels are deployed

bash

# Blacklist the ovpn module until the patched kernel is deployed
echo "blacklist ovpn" | sudo tee /etc/modprobe.d/blacklist-ovpn.conf
sudo update-initramfs -u
# Verify the module is not loaded after reboot
lsmod | grep ovpn