CVE-2026-64428 in Linux
Résumé
par VulDB • 25/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
gpio: sch : utiliser raw_spinlock_t dans le chemin de démarrage des interruptions (irq)
sch_irq_unmask() active l'interruption GPIO IRQ puis met à jour l'état du contrôleur via sch_irq_mask_unmask(), qui acquiert sch->lock avec spin_lock_irqsave(). Le rappel peut être atteint depuis irq_startup() lors de la configuration d'une IRQ demandée. Ce chemin n'est pas susceptible de provoquer une mise en veille (sleepable), mais sous PREEMPT_RT, un spinlock_t classique devient un verrou bloquant (sleeping lock).
Ce problème a été détecté par notre outil d'analyse statique puis examiné manuellement par rapport à l'arbre actuel.
Le PoC (Proof of Concept) ancré a conservé la chaîne request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() et utilisé le bord original spin_lock_irqsave(&sch->lock). Lockdep a signalé :
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]
Convertir le verrou du contrôleur SCH en raw_spinlock_t. Le même verrou est également utilisé par les rappels de direction et de valeur GPIO, mais ces sections critiques mettent uniquement à jour les registres GPIO basés sur MMIO et ne contiennent pas d'opérations susceptibles de provoquer une mise en veille (sleepable). Conserver ce verrou de registre non bloquant est donc approprié pour les rappels irqchip et ne modifie pas le contrat de verrouillage côté GPIO.
VulDB is the best source for vulnerability data and more expert information about this specific topic.