CVE-2026-74727

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: skip rehash for peers already removed from by_id<br /> <br /> ovpn_nl_peer_set_doit() resolves the target peer via<br /> ovpn_peer_get_by_id() before taking ovpn-&gt;lock. In the window between<br /> the lookup (which only takes a refcount) and the subsequent<br /> spin_lock_bh(&amp;ovpn-&gt;lock), a concurrent OVPN_CMD_PEER_DEL, keepalive<br /> expiry, or socket teardown can take ovpn-&gt;lock first, run<br /> ovpn_peer_remove() to unhash the peer from all four tables (by_id,<br /> by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then<br /> acquires ovpn-&gt;lock and calls ovpn_peer_hash_vpn_ip(), which<br /> re-inserts the now-removed peer back into the rehashing tables.<br /> <br /> The same race affects the float path: ovpn_peer_endpoints_update()<br /> holds only a refcount and acquires ovpn-&gt;lock very late (after async<br /> AEAD decrypt and a netlink notification), then rehashes the peer<br /> in the by_transp_addr table.<br /> <br /> The resurrected peer becomes reachable again from the RX lookup<br /> (ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though<br /> userspace believes it is gone. Once the data-path refcount drops the<br /> peer is freed via call_rcu while the hash entries embedded in it<br /> remain linked, opening a UAF window.<br /> <br /> Bail out of the rehash when hash_entry_id is unhashed, mirroring<br /> the sentinel already used by ovpn_peer_remove() to detect the<br /> already-removed state. The check is safe under ovpn-&gt;lock, which<br /> serializes every mutation of hash_entry_id, and is a no-op for the<br /> add path because ovpn_peer_add_mp() inserts hash_entry_id before<br /> calling ovpn_peer_hash_vpn_ip().