CVE-2026-72063 in Linux
Résumé
par VulDB • 17/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
gpio: tegra : ne pas appeler pinctrl pour la direction des GPIO
tegra_gpio_direction_input() et tegra_gpio_direction_output() programment déjà directement les registres de direction du contrôleur GPIO. Les appels supplémentaires à pinctrl_gpio_direction_input/output() n'ajoutent aucune opération pinctrl Tegra, car les opérations pinmux de Tegra gèrent la demande/libération des GPIO mais ne disposent pas d'un hook gpio_set_direction.
L'appel supplémentaire entre tout de même dans le noyau pinctrl et acquiert pctldev->mutex. Les utilisateurs partagés de GPIO peuvent appeler le chemin de direction tout en maintenant leur spinlock par ligne ; cet appel pinctrl de direction autrement redondant peut donc dormir (faire un sleep) dans un contexte atomique.
Cela a été détecté par notre outil d'analyse statique, puis confirmé par une revue manuelle de tegra_gpio_probe(), des rappels de direction GPIO Tegra et des opérations pinctrl Tegra. Le chemin révisé possède un struct gpio_chip non dormant par défaut, tandis que la callback de direction entre toujours dans le chemin du mutex pinctrl.
Une validation d'exécution dirigée a conservé l'enregistrement du chip non dormant et a entraîné :
gpio_shared_proxy_direction_output() gpiod_direction_output_raw_commit() tegra_gpio_direction_output() pinctrl_gpio_direction_output()
Lockdep a signalé un avertissement de sleep-in-atomic (dormir dans un contexte atomique) avec le spinlock GPIO partagé maintenu et les fonctions pinctrl_get_device_gpio_range() ainsi que tegra_gpio_direction_output() présentes sur la pile d'appels.
Ne marquez pas l'ensemble du chip comme can_sleep pour masquer ce problème : can_sleep décrit si get()/set() peuvent dormir, et l'accès aux valeurs Tegra est de type MMIO (mémoire mappée en mémoire). Supprimez les appels pinctrl direction redondants et conservez la participation de pinctrl dans le chemin d'origine request/free.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.