CVE-2026-74727 in Linux
Summary
by MITRE • 08/22/2026
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().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability in question resides within the OpenVPN implementation for the Linux kernel, specifically affecting the peer management logic during state transitions. The core issue is a race condition that arises from improper synchronization between reference counting and lock acquisition when modifying or removing peers. In the function ovpn_nl_peer_set_doit(), which handles netlink commands to modify peer settings, the code first resolves the target peer using ovpn_peer_get_by_id(). This operation increments the peer's reference count but does not acquire the main spinlock protecting the hash tables. There is a critical window between this lookup and the subsequent acquisition of ovpn->lock via spin_lock_bh. During this interval, concurrent operations such as an explicit OVPN_CMD_PEER_DEL command, keepalive expiration triggering automatic removal, or socket teardown can execute. These operations are capable of acquiring ovpn->lock first, invoking ovpn_peer_remove(), which unhashes the peer from all four internal tables: by_id, by_vpn_addr4, by_vpn_addr6, and by_transp_addr. Once these entries are removed, the lock is released. When the original thread finally acquires the lock in set_doit, it proceeds to call ovpn_peer_hash_vpn_ip(), which blindly re-inserts the peer back into the hash tables despite the fact that userspace has already requested its removal and the peer object may be logically deleted from the system's active view.
A similar race condition exists within the float path of the implementation. The function ovpn_peer_endpoints_update() also relies on a reference count without holding the main lock during critical sections involving asynchronous AEAD decryption and netlink notifications. It acquires ovpn->lock only after these operations are complete, at which point it attempts to rehash the peer in the by_transp_addr table. This delayed locking strategy allows for similar concurrency issues where the state of the peer may have changed significantly between the initial reference acquisition and the final hash update. The consequence of this race is that a peer marked for deletion becomes reachable again through RX lookup via ovpn_peer_get_by_transp_addr and TX VPN-IP lookups, creating an inconsistent state where userspace believes the peer is gone while the kernel data structures still treat it as active. This inconsistency undermines the integrity of connection management and can lead to unexpected behavior in network traffic routing and policy enforcement.
The most severe impact of this vulnerability is a Use-After-Free (UAF) scenario that compromises memory safety within the kernel space. Once the race condition allows the peer to be resurrected in the hash tables, it remains linked even as other parts of the system attempt to clean up resources associated with the deleted peer. Specifically, when the data-path reference count for the peer eventually drops to zero, the kernel frees the peer object using call_rcu, which schedules the memory deallocation after a grace period. However, because the hash entries embedded within the peer structure remain linked in the global tables due to the race condition, these dangling pointers persist. Any subsequent lookup that traverses these hash tables will access the freed memory region, leading to undefined behavior, potential kernel panics, or arbitrary code execution if an attacker can control the contents of the reclaimed memory. This represents a critical security flaw as it allows for exploitation through standard network operations without requiring elevated privileges beyond those needed to send netlink commands or trigger keepalive timeouts.
To mitigate this vulnerability, the fix involves modifying the rehashing logic to check whether the peer has already been unhashed before attempting to insert it back into the tables. Specifically, the code now bails out of the rehash operation if hash_entry_id is found to be unhashed. This check is safe under ovpn->lock because this lock serializes every mutation of hash_entry_id, ensuring that the state observed by the thread holding the lock reflects the most recent modifications made by any other concurrent process. For the add path, specifically in ovpn_peer_add_mp(), the logic remains unchanged as it inserts hash_entry_id before calling ovpn_peer_hash_vpn_ip(), so this check acts as a no-op for new peers while effectively preventing the resurrection of deleted ones. This approach aligns with industry standards such as CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and addresses the root cause by ensuring that state transitions are atomic relative to hash table modifications. From an ATT&CK perspective, this vulnerability could be leveraged in techniques related to Defense Evasion or Privilege Escalation if exploited to crash the system or execute code within kernel context. System administrators should apply the latest kernel patches immediately and ensure that netlink interfaces controlling OpenVPN peers are restricted to trusted userspace processes to minimize the attack surface for triggering these race conditions.