CVE-2026-98520
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
drm/amdkfd: corregir use-after-free y la brecha entre contenedores en kfd_dev_mapping
kfd_dev_mapping almacena en caché el address_space del primer proceso que abrió /dev/kfd para que la ruta de reinicio de la GPU pueda llamar a unmap_mapping_range() y eliminar todos los mapeos del espacio de usuario de los rangos de doorbell y MMIO. Este diseño presenta dos fallos que se manifiestan con SRIOV y varios contenedores:
1. Use-after-free (uso de memoria liberada) y bloqueo del rwsem. El puntero almacenado en caché hace referencia a un inodo perteneciente al contenedor del primer proceso que lo abrió.
Leer descripción completaMostrar menos
Cuando ese contenedor finaliza y su inodo se libera, kfd_dev_mapping pasa a ser un puntero colgante. Un reinicio posterior de la GPU lo desreferencia dentro de unmap_mapping_range(), que adquiere i_mmap_rwsem sobre el inodo liberado, provocando un bloqueo total observable como una espera rwsem no interrumpible.
2. Brecha entre contenedores. Solo se almacena en caché el address_space del primer proceso que abrió el dispositivo; las VMA creadas por los procesos que lo abrieron después residen en otro address_space y nunca son alcanzadas por unmap_mapping_range(). Tras un reinicio de la GPU, esos mapeos obsoletos mantienen accesibles para el espacio de usuario invitado las páginas de doorbell y MMIO sin que haya una GPU detrás, con el riesgo de que se produzcan tiempos de espera de transacciones PCIe y pánicos NMI.
Ambos fallos se corrigen con el mismo enfoque que usa el núcleo de DRM (drm_drv.c): crear un pseudo-sistema de archivos privado en el momento de la carga del módulo y asignar a partir de él un único inodo anónimo. En kfd_open() se redirige el file->f_mapping de cada proceso que abre el dispositivo al address_space de ese inodo. El inodo pertenece al módulo, vive exactamente mientras viva el módulo amdgpu y reúne las VMA de todos los procesos que lo abren en un único address_space. Una sola llamada a unmap_mapping_range() en la ruta de reinicio alcanza así correctamente los mapeos de todos los contenedores, sin riesgo de puntero colgante.
El bloqueo se manifiesta como un backtrace NMI en el workqueue de reinicio de la GPU atascado en un bucle de espera dentro de rwsem_down_read_slowpath() con un i_mmap_rwsem corrupto:
(cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c)
Detalles técnicos trazas, registros y código del informe original
Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu] Call Trace: <TASK> kvm_wait+0x1f/0x40 __pv_queued_spin_lock_slowpath+0x31d/0x3a0 _raw_spin_lock_irq+0x51/0x80 rwsem_down_read_slowpath+0xb3/0x550 down_read+0x48/0xd0 unmap_mapping_range+0x71/0x140 kfd_dev_unmap_mapping_range+0x5b/0x140 [amdgpu] amdgpu_amdkfd_clear_kfd_mapping+0xd8/0x190 [amdgpu] amdgpu_device_gpu_recover+0x232/0x450 [amdgpu] xgpu_ai_mailbox_flr_work+0xb5/0xc0 [amdgpu] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230
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.20 %
- Percentil entre todas las CVEs puntuadas
- 9
- 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-98520",
"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": "70cadefcc6160c575b04f763ada34c20e868d577",
"lessThan": "02b74891624e09a5512c6d84f267d01fcc306a3b",
"versionType": "git"
},
{
"status": "affected",
"version": "70cadefcc6160c575b04f763ada34c20e868d577",
"lessThan": "c3a31087b1c8df679b653c1a09d9abe5ff7ec8ef",
"versionType": "git"
}
],
"programFiles": [
"drivers/gpu/drm/amd/amdkfd/kfd_chardev.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "7.2"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "7.2",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "7.2.9",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/gpu/drm/amd/amdkfd/kfd_chardev.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-10-18T16:17:03.370",
"references": [
{
"url": "https://git.kernel.org/stable/c/02b74891624e09a5512c6d84f267d01fcc306a3b",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/c3a31087b1c8df679b653c1a09d9abe5ff7ec8ef",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping\n\nkfd_dev_mapping caches the address_space of the first /dev/kfd opener\nso that the GPU reset path can call unmap_mapping_range() to zap all\nuserspace mappings of doorbell and MMIO ranges. This design has two\nbugs that both manifest under SRIOV with multiple containers:\n\n1. Use-after-free / rwsem deadlock. The cached pointer refers to an\n inode owned by the first opener's container. When that container\n exits and its inode is released, kfd_dev_mapping becomes a dangling\n pointer. A subsequent GPU reset dereferences it inside\n unmap_mapping_range(), which takes i_mmap_rwsem on the freed inode,\n causing a hard hang observable as an uninterruptible rwsem wait.\n\n2. Multi-container gap. Only the first opener's address_space is cached;\n VMAs created by later openers live in a different address_space and\n are never reached by unmap_mapping_range(). After a GPU reset those\n stale mappings keep doorbell and MMIO pages accessible to guest\n userspace with no GPU behind them, risking PCIe transaction timeouts\n and NMI panics.\n\nFix both bugs with the same approach used by DRM core (drm_drv.c):\ncreate a private pseudo-filesystem at module init time and allocate one\nanonymous inode from it. In kfd_open() redirect every opener's\nfile->f_mapping to that inode's address_space. The inode is\nmodule-owned, lives exactly as long as the amdgpu module, and collects\nVMAs from all openers in one address_space. A single\nunmap_mapping_range() call in the reset path then correctly reaches\nevery container's mappings with no dangling pointer risk.\n\nThe hang manifests as an NMI backtrace on the GPU reset workqueue stuck\nspinning in rwsem_down_read_slowpath() with a corrupted i_mmap_rwsem:\n\n Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu]\n Call Trace:\n <TASK>\n kvm_wait+0x1f/0x40\n __pv_queued_spin_lock_slowpath+0x31d/0x3a0\n _raw_spin_lock_irq+0x51/0x80\n rwsem_down_read_slowpath+0xb3/0x550\n down_read+0x48/0xd0\n unmap_mapping_range+0x71/0x140\n kfd_dev_unmap_mapping_range+0x5b/0x140 [amdgpu]\n amdgpu_amdkfd_clear_kfd_mapping+0xd8/0x190 [amdgpu]\n amdgpu_device_gpu_recover+0x232/0x450 [amdgpu]\n xgpu_ai_mailbox_flr_work+0xb5/0xc0 [amdgpu]\n process_one_work+0x18e/0x3e0\n worker_thread+0x2e3/0x420\n kthread+0x10a/0x230\n\n(cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c)"
}
],
"lastModified": "2026-10-19T10:19:05.910",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}