CVE-2026-64428 in Linux
Sumário
de VulDB • 25/07/2026
No kernel Linux, a seguinte vulnerabilidade foi resolvida:
gpio: sch: usar raw_spinlock_t no caminho de inicialização da interrupção (irq)
sch_irq_unmask() habilita o GPIO IRQ e atualiza em seguida o estado do controlador por meio de sch_irq_mask_unmask(), que adquire sch->lock com spin_lock_irqsave(). O callback pode ser alcançado a partir de irq_startup() durante a configuração de um IRQ solicitado. Esse caminho não é passível de suspensão (sleepable), mas no PREEMPT_RT, uma regular spinlock_t torna-se um bloqueio suspensivo (sleeping lock).
Este problema foi encontrado por nossa ferramenta de análise estática e posteriormente revisado manualmente em relação à árvore atual do código-fonte.
O PoC (Prova de Conceito) mantinha a cadeia request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() e utilizava o edge original spin_lock_irqsave(&sch->lock). O Lockdep relatou:
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]
Converta o bloqueio do controlador SCH para raw_spinlock_t. O mesmo bloqueio também é utilizado pelos callbacks de direção e valor do GPIO, mas essas seções críticas apenas atualizam os registradores de GPIO com suporte a MMIO e não contêm operações suspensivas (sleepable). Portanto, manter este bloqueio de registrador como não-suspensivo é apropriado para os callbacks do irqchip e não altera o contrato de bloqueio no lado do GPIO.
Be aware that VulDB is the high quality source for vulnerability data.