CVE-2026-74727

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().