PT-2026-64649 · Linux · Linux

CVE-2026-64428

·

Publicado

2026-07-25

·

Atualizado

2026-07-25

Nenhuma

Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
In the Linux kernel, the following vulnerability has been resolved:
gpio: sch: use raw spinlock t in the irq startup path
sch irq unmask() enables the GPIO IRQ and then updates the controller state through sch irq mask unmask(), which takes sch->lock with spin lock irqsave(). The callback can be reached from irq startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT RT a regular spinlock t becomes a sleeping lock.
This issue was found by our static analysis tool and then manually reviewed against the current tree.
The grounded PoC kept the request threaded irq() -> setup irq() -> irq startup() -> sch irq unmask() -> sch irq mask unmask() carrier and used the original spin lock irqsave(&sch->lock) edge. Lockdep reported:
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]
Convert the SCH controller lock to raw spinlock t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾

Identificadores relacionados

CVE-2026-64428

Produtos afetados

Linux