CVE-2026-74727
ovpn: skip rehash for peers already removed from by_id
Description
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().
INFO
Published Date :
Aug. 22, 2026, 4:16 p.m.
Last Modified :
Oct. 14, 2026, 1:10 p.m.
Remotely Exploit :
Yes !
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | CRITICAL | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
Solution
- Apply the kernel patch for ovpn: skip rehash for peers.
- Ensure hash_entry_id is checked before rehashing.
- Update the Linux kernel to the patched version.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-74727.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-74727 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-74727
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-74727 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-74727 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Translated by [email protected]
Oct. 14, 2026
Action Type Old Value New Value Added Translation Title: Linux, Description: En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ovpn: omitir el rehash para pares ya eliminados de by_id ovpn_nl_peer_set_doit() resuelve el par objetivo a través de ovpn_peer_get_by_id() antes de tomar ovpn -> lock. En la ventana entre la búsqueda (que solo toma un refcount) y el subsiguiente spin_lock_bh(&ovpn -> lock), un OVPN_CMD_PEER_DEL concurrente, la expiración de un keepalive o el cierre de un socket pueden tomar ovpn -> lock primero, ejecutar ovpn_peer_remove() para deshashear el par de las cuatro tablas (by_id, by_vpn_addr4/6, by_transp_addr) y liberar el bloqueo. set_doit luego adquiere ovpn -> lock y llama a ovpn_peer_hash_vpn_ip(), lo que reinserta el par ahora eliminado de nuevo en las tablas de rehashing. La misma condición de carrera afecta la ruta flotante: ovpn_peer_endpoints_update() solo mantiene un refcount y adquiere ovpn -> lock muy tarde (después de un descifrado AEAD asíncrono y una notificación netlink), luego rehashea el par en la tabla by_transp_addr. El par resucitado vuelve a ser accesible desde la búsqueda RX (ovpn_peer_get_by_transp_addr) y la búsqueda TX VPN-IP, aunque el userspace cree que ha desaparecido. Una vez que el refcount de la ruta de datos disminuye, el par es liberado a través de call_rcu mientras que las entradas de hash incrustadas en él permanecen vinculadas, abriendo una ventana UAF. Salir del rehash cuando hash_entry_id es deshasheado, reflejando el centinela ya utilizado por ovpn_peer_remove() para detectar el estado ya eliminado. La verificación es segura bajo ovpn -> lock, que serializa cada mutación de hash_entry_id, y es una operación nula para la ruta de adición porque ovpn_peer_add_mp() inserta hash_entry_id antes de llamar a ovpn_peer_hash_vpn_ip(). -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 25, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 22, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '1d36a36f6d5347360ef9681a05f6166683bafd1d', 'lessThan': 'd20c181088984b6eaa8d7fe7cb5ab3510988df59', 'versionType': 'git'}, {'status': 'affected', 'version': '1d36a36f6d5347360ef9681a05f6166683bafd1d', 'lessThan': '66745480298775f188b2f5ad266643e85a90f73b', 'versionType': 'git'}, {'status': 'affected', 'version': '1d36a36f6d5347360ef9681a05f6166683bafd1d', 'lessThan': '33ec10567fe14456063daf549fdf1a4f53448e4c', 'versionType': 'git'}], 'programFiles': ['drivers/net/ovpn/peer.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '6.16'}, {'status': 'unaffected', 'version': '0', 'lessThan': '6.16', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '6.18.45', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '7.1.9', 'versionType': 'semver', 'lessThanOrEqual': '7.1.*'}, {'status': 'unaffected', 'version': '7.2', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['drivers/net/ovpn/peer.c'], 'defaultStatus': 'affected'}] Added Description 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(). Added Reference https://git.kernel.org/stable/c/33ec10567fe14456063daf549fdf1a4f53448e4c Added Reference https://git.kernel.org/stable/c/66745480298775f188b2f5ad266643e85a90f73b Added Reference https://git.kernel.org/stable/c/d20c181088984b6eaa8d7fe7cb5ab3510988df59