The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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(). (CVE-2026-74727)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2026-74727

critical Nessus Plugin ID 339022

Version 1.7