CVE-2026-74727

In the Linux kernel, the following vulnerability has been resolved:

ovpn: skip rehash for peers already removed from by_id

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 OVPNCMDPEER_DEL, keepalive

expiry, or socket teardown can take ovpn->lock first, run

ovpnpeerremove() to unhash the peer from all four tables (by_id,

byvpnaddr4/6, bytranspaddr) and release the lock. set_doit 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: ovpnpeerendpoints_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 bytranspaddr table.

The resurrected peer becomes reachable again from the RX lookup

(ovpnpeergetbytransp_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 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 hashentry_id before

calling ovpnpeerhashvpnip().