CVE-2026-64428 in Linux
Resumen
por VulDB • 2026-07-26
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
gpio: sch: usar raw_spinlock_t en la ruta de inicio de las interrupciones (irq)
sch_irq_unmask() habilita la IRQ del GPIO y luego actualiza el estado del controlador a través de sch_irq_mask_unmask(), que toma sch->lock con spin_lock_irqsave(). La función de llamada puede alcanzarse desde irq_startup() durante la configuración de una IRQ solicitada. Esa ruta no es susceptible al bloqueo por sueño (sleepable), pero en PREEMPT_RT un spinlock_t regular se convierte en un lock susceptible a bloqueos por sueño.
Este problema fue encontrado por nuestra herramienta de análisis estático y luego revisado manualmente contra el árbol actual del código fuente.
El PoC (Prueba de Concepto) mantuvo la cadena request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() y utilizó el borde original spin_lock_irqsave(&sch->lock). Lockdep informó:
BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]
__setup_irq.constprop.0+0xd/0x30 [vuln_msv]
Convierta el lock del controlador SCH a raw_spinlock_t. El mismo lock también es utilizado por las funciones de llamada (callbacks) de dirección y valor del GPIO, pero esas secciones críticas solo actualizan registros GPIO respaldados por MMIO y no contienen operaciones susceptibles al bloqueo por sueño. Por lo tanto, mantener este lock de registro como no susceptible a bloqueos por sueño es apropiado para los callbacks de irqchip y no cambia el contrato de locking en el lado del GPIO.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.