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 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 ovpnpeerhashvpn_ip(), 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 bytransp_addr 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 ovpnpeerhashvpn_ip().