FKIE_CVE-2026-74727
Vulnerability from fkie_nvd - Published: 2026-08-22 16:16 - Updated: 2026-10-14 13:10
Severity
Summary
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().
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ovpn/peer.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d20c181088984b6eaa8d7fe7cb5ab3510988df59",
"status": "affected",
"version": "1d36a36f6d5347360ef9681a05f6166683bafd1d",
"versionType": "git"
},
{
"lessThan": "66745480298775f188b2f5ad266643e85a90f73b",
"status": "affected",
"version": "1d36a36f6d5347360ef9681a05f6166683bafd1d",
"versionType": "git"
},
{
"lessThan": "33ec10567fe14456063daf549fdf1a4f53448e4c",
"status": "affected",
"version": "1d36a36f6d5347360ef9681a05f6166683bafd1d",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ovpn/peer.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.16"
},
{
"lessThan": "6.16",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.45",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.1.*",
"status": "unaffected",
"version": "7.1.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.2",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\novpn: skip rehash for peers already removed from by_id\n\novpn_nl_peer_set_doit() resolves the target peer via\novpn_peer_get_by_id() before taking ovpn-\u003elock. In the window between\nthe lookup (which only takes a refcount) and the subsequent\nspin_lock_bh(\u0026ovpn-\u003elock), a concurrent OVPN_CMD_PEER_DEL, keepalive\nexpiry, or socket teardown can take ovpn-\u003elock first, run\novpn_peer_remove() to unhash the peer from all four tables (by_id,\nby_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then\nacquires ovpn-\u003elock and calls ovpn_peer_hash_vpn_ip(), which\nre-inserts the now-removed peer back into the rehashing tables.\n\nThe same race affects the float path: ovpn_peer_endpoints_update()\nholds only a refcount and acquires ovpn-\u003elock very late (after async\nAEAD decrypt and a netlink notification), then rehashes the peer\nin the by_transp_addr table.\n\nThe resurrected peer becomes reachable again from the RX lookup\n(ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though\nuserspace believes it is gone. Once the data-path refcount drops the\npeer is freed via call_rcu while the hash entries embedded in it\nremain linked, opening a UAF window.\n\nBail out of the rehash when hash_entry_id is unhashed, mirroring\nthe sentinel already used by ovpn_peer_remove() to detect the\nalready-removed state. The check is safe under ovpn-\u003elock, which\nserializes every mutation of hash_entry_id, and is a no-op for the\nadd path because ovpn_peer_add_mp() inserts hash_entry_id before\ncalling ovpn_peer_hash_vpn_ip()."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\novpn: omitir el rehash para pares ya eliminados de by_id\n\novpn_nl_peer_set_doit() resuelve el par objetivo a trav\u00e9s de ovpn_peer_get_by_id() antes de tomar ovpn -\u003e lock. En la ventana entre la b\u00fasqueda (que solo toma un refcount) y el subsiguiente spin_lock_bh(\u0026ovpn -\u003e lock), un OVPN_CMD_PEER_DEL concurrente, la expiraci\u00f3n de un keepalive o el cierre de un socket pueden tomar ovpn -\u003e 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 -\u003e lock y llama a ovpn_peer_hash_vpn_ip(), lo que reinserta el par ahora eliminado de nuevo en las tablas de rehashing.\n\nLa misma condici\u00f3n de carrera afecta la ruta flotante: ovpn_peer_endpoints_update() solo mantiene un refcount y adquiere ovpn -\u003e lock muy tarde (despu\u00e9s de un descifrado AEAD as\u00edncrono y una notificaci\u00f3n netlink), luego rehashea el par en la tabla by_transp_addr.\n\nEl par resucitado vuelve a ser accesible desde la b\u00fasqueda RX (ovpn_peer_get_by_transp_addr) y la b\u00fasqueda 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\u00e9s de call_rcu mientras que las entradas de hash incrustadas en \u00e9l permanecen vinculadas, abriendo una ventana UAF.\n\nSalir 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\u00f3n es segura bajo ovpn -\u003e lock, que serializa cada mutaci\u00f3n de hash_entry_id, y es una operaci\u00f3n nula para la ruta de adici\u00f3n porque ovpn_peer_add_mp() inserta hash_entry_id antes de llamar a ovpn_peer_hash_vpn_ip()."
}
],
"id": "CVE-2026-74727",
"lastModified": "2026-10-14T13:10:00.187",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.8,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-08-22T16:16:47.813",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/33ec10567fe14456063daf549fdf1a4f53448e4c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/66745480298775f188b2f5ad266643e85a90f73b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d20c181088984b6eaa8d7fe7cb5ab3510988df59"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.