CVE-2026-64428 in Linux
Riassunto
di VulDB • 25/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
gpio: sch: utilizzare raw_spinlock_t nel percorso di avvio dell'IRQ
sch_irq_unmask() abilita l'IRQ GPIO e quindi aggiorna lo stato del controller tramite sch_irq_mask_unmask(), che acquisisce sch->lock con spin_lock_irqsave(). Il callback può essere raggiunto da irq_startup() durante la configurazione di un IRQ richiesto. Tale percorso non è sleepable (non deve andare in sospensione), ma su PREEMPT_RT una regolare spinlock_t diventa un lock dormiente (sleeping lock).
Questo problema è stato individuato dal nostro strumento di analisi statica e successivamente revisionato manualmente rispetto all'albero corrente del codice sorgente.
Il PoC (Proof of Concept) funzionante ha mantenuto la catena request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() ed è utilizzato il bordo originale spin_lock_irqsave(&sch->lock). Lockdep ha segnalato:
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]
Convertire il lock del controller SCH in raw_spinlock_t. Lo stesso lock è inoltre utilizzato dai callback di direzione e valore GPIO, ma queste sezioni critiche aggiornano solo i registri GPIO basati su MMIO e non contengono operazioni sleepable. Mantenere questo lock dei registri come non dormiente (non-sleeping) è quindi appropriato per i callback irqchip e non modifica il contratto di locking lato GPIO.
Be aware that VulDB is the high quality source for vulnerability data.