CVE-2026-74727
Received Received - Intake

Race Condition in OpenVPN Kernel Module Leads to Use-After-Free

Publication date: 2026-08-22

Last updated on: 2026-08-22

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: ovpn: skip rehash for peers already removed from by_id ovpn_nl_peer_set_doit() resolves the target peer via ovpn_peer_get_by_id() before taking ovpn->lock. In the window between the lookup (which only takes a refcount) and the subsequent spin_lock_bh(&ovpn->lock), a concurrent OVPN_CMD_PEER_DEL, keepalive expiry, or socket teardown can take ovpn->lock first, run ovpn_peer_remove() to unhash the peer from all four tables (by_id, by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then acquires ovpn->lock and calls ovpn_peer_hash_vpn_ip(), which re-inserts the now-removed peer back into the rehashing tables. The same race affects the float path: ovpn_peer_endpoints_update() holds only a refcount and acquires ovpn->lock very late (after async AEAD decrypt and a netlink notification), then rehashes the peer in the by_transp_addr table. The resurrected peer becomes reachable again from the RX lookup (ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though userspace believes it is gone. Once the data-path refcount drops the peer is freed via call_rcu while the hash entries embedded in it remain linked, opening a UAF window. Bail out of the rehash when hash_entry_id is unhashed, mirroring the sentinel already used by ovpn_peer_remove() to detect the already-removed state. The check is safe under ovpn->lock, which serializes every mutation of hash_entry_id, and is a no-op for the add path because ovpn_peer_add_mp() inserts hash_entry_id before calling ovpn_peer_hash_vpn_ip().

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-22
Last Modified
2026-08-22
Generated
2026-08-22
AI Q&A
2026-08-22
EPSS Evaluated
N/A
NVD
CVE-2026-74727
EUVD
EUVD-2026-64414

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 is a race condition in the Linux kernel's OpenVPN implementation. It occurs when a peer is removed but then incorrectly reinserted into routing tables due to a timing window between lookup and locking. This creates a use-after-free scenario where the peer's memory can be accessed after it should have been freed.

Detection Guidance

This vulnerability is specific to the Linux kernel's OpenVPN implementation and involves race conditions in peer management. Detection requires kernel-level monitoring for unusual peer rehashing behavior or UAF conditions in ovpn module. No standard commands are provided for detection as it requires specialized kernel tracing or debugging tools.

Impact Analysis

An attacker could exploit this to cause system instability, crashes, or potentially execute arbitrary code with kernel privileges. It may allow unauthorized network access or denial of service by manipulating peer connections.

Mitigation Strategies

Apply the latest kernel patches addressing this issue. Monitor for peer removal anomalies in OpenVPN logs. Restart OpenVPN services after patching to ensure clean state. Avoid using vulnerable kernel versions until patched.

Chat Assistant

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

EPSS Chart