CVE-2026-74727: ovpn: skip rehash for peers already removed from by_id
In the Linux kernel, the following vulnerability has been resolved:
ovpn: skip rehash for peers already removed from byid
ovpnnlpeersetdoit() resolves the target peer via ovpnpeergetbyid() before taking ovpn->lock. In the window between the lookup (which only takes a refcount) and the subsequent spinlockbh(&ovpn->lock), a concurrent OVPNCMDPEERDEL, keepalive expiry, or socket teardown can take ovpn->lock first, run ovpnpeerremove() to unhash the peer from all four tables (byid, byvpnaddr4/6, bytranspaddr) and release the lock. setdoit then acquires ovpn->lock and calls ovpnpeerhashvpnip(), which re-inserts the now-removed peer back into the rehashing tables.
The same race affects the float path: ovpnpeerendpointsupdate() holds only a refcount and acquires ovpn->lock very late (after async AEAD decrypt and a netlink notification), then rehashes the peer in the bytranspaddr table.
The resurrected peer becomes reachable again from the RX lookup (ovpnpeergetbytranspaddr) and the TX VPN-IP lookup, even though userspace believes it is gone. Once the data-path refcount drops the peer is freed via callrcu while the hash entries embedded in it remain linked, opening a UAF window.
Bail out of the rehash when hashentryid is unhashed, mirroring the sentinel already used by ovpnpeerremove() to detect the already-removed state. The check is safe under ovpn->lock, which serializes every mutation of hashentryid, and is a no-op for the add path because ovpnpeeraddmp() inserts hashentryid before calling ovpnpeerhashvpnip().
Affected Software
Event History
Frequently Asked Questions
What conditions are needed to trigger the race?
A peer update or endpoint-float operation must resolve a peer and retain only a reference while a concurrent peer deletion, keepalive expiry, or socket teardown removes that peer under ovpn->lock. The update path can then acquire the lock later and reinsert the removed peer into lookup tables.
Who is exposed to this issue?
Systems using the Linux kernel ovpn implementation are exposed when peer-set or endpoint-update activity can race with peer removal. The affected paths include netlink peer updates and the float path following asynchronous AEAD decryption and a netlink notification.
What can happen after a removed peer is resurrected?
The peer can again be found through receive transport-address lookup and transmit VPN-IP lookup even though userspace considers it deleted. After its data-path reference count drops, it may be freed through call_rcu while embedded hash entries remain linked.