CVE-2026-98654 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
drm/amd/display: Atomizar las operaciones de lectura/modificación/escritura (RMW) de los registros de interrupciones (IRQ)
[Por qué]
El registro OTG_GLOBAL_SYNC_STATUS controla varias fuentes de IRQ del hardware para el generador de temporización de salida (OTG). VUPDATE_NO_LOCK es una de ellas.
Para habilitar la IRQ, el controlador establece el bit VUPDATE_NO_LOCK_EN en el registro GLOBAL_SYNC_STATUS.
Para confirmar (ack) la IRQ después de que se active, el controlador establece el bit VUPDATE_NO_LOCK_CLEAR en el mismo registro GLOBAL_SYNC_STATUS.
La configuración de estos bits se realiza mediante operaciones de lectura/modificación/escritura, las cuales no son atómicas. Por lo tanto, es posible la siguiente condición de carrera (race condition):
Hilo A: Controlador de IRQ: *Se activa una IRQ del HW* # Deshabilitar IRQ val = read(GLOBAL_SYNC_STATUS) unset(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # La confirmación (ACK) lee que VUPDATE_NO_LOCK_EN está desactivado val1 = read(GLOBAL_SYNC_STATUS) set(val1, VUPDATE_NO_LOCK_CLEAR) # Habilitar IRQ val = read(GLOBAL_SYNC_STATUS) set(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # ¡MALO! desactiva VUPDATE_NO_LOCK_EN write(val1, GLOBAL_SYNC_STATUS)
En cuanto al cambio de la etiqueta Fixes: parece que el cambio realizado hizo que esta condición de carrera fuera más probable. Dado que VUPDATE_NO_LOCK es ahora la única fuente de IRQ para el manejo de vblank, una sola condición de carrera en paneles con alta tasa de refresco puede provocar un tiempo de espera (timeout).
[Cómo]
El registro GLOBAL_SYNC_STATUS es solo un ejemplo; otros registros de control de IRQ también comparten el mismo esquema. Además de GLOBAL_SYNC_STATUS, limpiaremos también esos casos.
Para mantener las cosas simples, atomizaremos las operaciones RMW de IRQ mediante un único spinlock a nivel del driver. Debido al pequeño alcance de este lock, es poco probable que cause una sobrecarga notable sobre todo el locking existente en los caminos (paths) de configuración/manejo de IRQs.
Dado que DM es responsable del bloqueo, envolveremos dc_interrupt_set/ack con el spinlock en las nuevas funciones amdgpu_dm_irq_set/ack. Migraremos o eliminaremos todas las referencias en DM a dc_interrupt_set/ack para usar amdgpu_dm_irq_set/ack en su lugar.
(cherry picked from commit 70de0a0216583a53c946155f8c8adedfdca6b4e7)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.