CVE-2026-98715
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad:
KVM: SVM: Preservar el control de TLB (es decir, el vaciado de TLB pendiente) en un VMRUN fallido
No restablecer el control de TLB de la VMCB a "no hacer nada" tras un VMRUN fallido, ya que las pruebas empíricas demuestran que la CPU realiza el vaciado de TLB solicitado si y solo si VMRUN se completa correctamente; es decir, borrar el control de TLB tras un VMRUN fallido descarta de hecho un vaciado de TLB.
Hacer explícito el seguimiento de la necesidad de vaciar todos los ASID por CPU, ya que la condición de reutilización de ASID está ligada a la pCPU, no a la vCPU.
Leer descripción completaMostrar menos
Como ventaja adicional, esto también elimina la necesidad de evitar sobrescribir FLUSH_ALL_ASID con TLB_CONTROL_FLUSH_ASID, por ejemplo en svm_flush_tlb_asid().
Se ha decidido deliberadamente no molestarse en guardar ni restaurar el "antiguo" tlb_ctl en caso de fallo; el término va entre comillas porque no es exactamente el tlb_ctl anterior, sino el tlb_ctl posterior a pre_svm_run() pero anterior a la actualización de tlb_ctl para flush_all_asids. Si VMRUN falla y se fuerza TLB_CONTROL_FLUSH_ALL_ASID, la siguiente ejecución correcta de la VMCB *podría* vaciar innecesariamente todos los ASID, lo que, estrictamente hablando, podría provocar problemas de vecino ruidoso (noisy neighbor). Sin embargo, el hecho de que new_asid() ya puede ser activado por el huésped, debido al comportamiento defectuoso de KVM de borrar el ASID en un INIT emulado, significa que un huésped ya puede provocar un vaciado de todos los ASID a aproximadamente la misma frecuencia. Y una vez que KVM deje de borrar el ASID en el INIT emulado, *o* asigne un ASID estático a cada vCPU, este defecto desaparece.
Traducción automática del texto original de NVD (en inglés).
CVSS
NVD no ha asignado puntuación CVSS a esta CVE (habitual desde el cambio de política de abril de 2026).
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días
- 0.19 %
- Percentil entre todas las CVEs puntuadas
- 8
- Fecha de la puntuación
- 20/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-98715",
"cveTags": [],
"metrics": {},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "38e5e92fe8c02a8766459d505423b855caf9af1f",
"lessThan": "fd873c3d1b5240e80365f09e758e8c96b88a7cdb",
"versionType": "git"
},
{
"status": "affected",
"version": "38e5e92fe8c02a8766459d505423b855caf9af1f",
"lessThan": "60d93c27859fb3ec5b5a689e24de303f166477d0",
"versionType": "git"
}
],
"programFiles": [
"arch/x86/kvm/svm/svm.c",
"arch/x86/kvm/svm/svm.h"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.38"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "2.6.38",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "7.2.10",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"arch/x86/kvm/svm/svm.c",
"arch/x86/kvm/svm/svm.h"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-10-18T16:17:25.050",
"references": [
{
"url": "https://git.kernel.org/stable/c/60d93c27859fb3ec5b5a689e24de303f166477d0",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/fd873c3d1b5240e80365f09e758e8c96b88a7cdb",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN\n\nDon't reset the VMCB's TLB control back to \"do nothing\" on a failed VMRUN,\nas empirical testing shows that the CPU performs the requested TLB flush if\nand only if VMRUN is successful, i.e. clearing TLB control on a failed\nVMRUN effectively drops a TLB flush.\n\nExplicitly track the need to flush all ASIDs on a per-CPU basis, as the\nASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus,\nthis also obviates the need to avoid clobbering FLUSH_ALL_ASID with\nTLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid().\n\nDeliberately don't bother saving/restoring the \"old\" tlb_ctl on failure,\nin quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from\nafter pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If\nVMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next\nsuccessful run of the VMCB *may* unnecessarily flush all ASIDs, which\nstrictly speaking could result in noisy neighbor issues. However, the\nfact that new_asid() is already guest-triggerable, because of KVM's flawed\nbehavior of clearing the ASID on emulated INIT, means that a guest can\nalready trigger a flush of all ASIDs at roughly the same rate. And once\nKVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID\nto each vCPU, this flaw goes away."
}
],
"lastModified": "2026-10-19T10:19:35.747",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}