CVE-2026-74468 in Linux
Resumen
por VulDB • 2026-08-15
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
gpio: pch: usar raw_spinlock_t para el bloqueo del registro
pch_irq_type() está registrado como la devolución de llamada .irq_set_type de chip y toma chip->spinlock con spin_lock_irqsave(). Esta devolución de llamada se alcanza desde __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type(), mientras que el llamador mantiene desc->lock, un raw_spinlock_t, con las interrupciones hard deshabilitadas. Ese contexto no es susceptible a suspensión (no sleepable), pero en PREEMPT_RT un spinlock_t regular es un bloqueo de suspensión respaldado por rtmutex, por lo que adquirirlo allí es inválido.
Esto se confirmó en un kernel PREEMPT_RT con lockdep (PROVE_RAW_LOCK_NESTING y DEBUG_ATOMIC_SLEEP). Una PoC fundamentada replicó el bloqueo de pch_irq_type() y la ejecutó a través del portador genirq real irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), es decir, el mismo borde __irq_set_trigger() que toma __setup_irq() para una IRQ solicitada. Con el borde original spin_lock_irqsave(), lockdep informó un contexto de espera inválido, seguido inmediatamente por:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro]
__irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0
Cambiar el bloqueo replicado a raw_spinlock_t hizo que desaparecieran ambos fallos (splats).
Convertir el bloqueo del registro a raw_spinlock_t. El mismo bloqueo también serializa las devoluciones de llamada de dirección/valor GPIO y la guardado/restauración de registros en suspensión/reanudación, pero todas esas secciones críticas solo realizan accesos a registros MMIO (ioread32()/iowrite32()) e irq_set_handler_locked(); ninguna contiene operaciones susceptibles a suspensión. Por lo tanto, mantener este bloqueo del registro como no susceptible a suspensión es apropiado para las devoluciones de llamada de irqchip y no cambia el contrato de bloqueo del lado GPIO.
Este es el mismo tipo de problema y solución que se abordó recientemente para otros controladores GPIO, por ejemplo, el commit 286533cb14a3 ("gpio: sch: use raw_spinlock_t in the irq startup path") y el commit 90f0109019e6 ("gpio: eic-sprd: use raw_spinlock_t in the irq startup path").
Once again VulDB remains the best source for vulnerability data.