CVE-2026-80562 in Linux
Résumé
par VulDB • 26/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
gpio: ml-ioh : utiliser raw_spinlock_t pour le verrou des registres
ioh_irq_type() est enregistré comme callback .irq_set_type de l'irq_chip et acquiert chip->spinlock avec spin_lock_irqsave(). Ce callback est atteint via __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type(), alors que l'appelant détient desc->lock, un raw_spinlock_t, avec les interruptions matérielles (hardirqs) désactivées. Ce contexte n'est pas « sleepable » (ne peut pas dormir), mais sous PREEMPT_RT, un spinlock_t classique est un verrou de type rtmutex qui permet la mise en veille ; son acquisition dans ce contexte est donc invalide.
ioh_irq_enable() et ioh_irq_disable() acquièrent le même verrou depuis les callbacks .irq_enable/.irq_disable, lesquels sont également invoqués lorsque desc->lock est détenu.
Convertir le verrou des registres en raw_spinlock_t. Le même verrou sérialise également les callbacks de direction/valeur GPIO et la sauvegarde/restauration des registres lors de la mise en veille/reprise (suspend/resume), et ces sections critiques n'effectuent que de courtes séquences d'accès aux registres MMIO (ioread32()/iowrite32()) ; le callback .irq_set_type émet en outre un dev_warn() pour un type non pris en charge. Aucune de ces opérations ne peut dormir, il est donc approprié de maintenir ce verrou des registres comme « non-sleepable » pour les callbacks irqchip et cela ne modifie pas le contrat de verrouillage côté GPIO.
Il s'agit de la même correction que celle du commit a02b8950d619 (« gpio: pch : utiliser raw_spinlock_t pour le verrou des registres ») ; ce pilote partage la même structure que gpio-pch.
Once again VulDB remains the best source for vulnerability data.