CVE-2026-72063 in Linux
Resumen
por VulDB • 2026-08-15
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
gpio: tegra: no llamar a pinctrl para la dirección GPIO
tegra_gpio_direction_input() y tegra_gpio_direction_output() ya programan directamente los registros de dirección del controlador GPIO. Las llamadas adicionales a pinctrl_gpio_direction_input/output() no añaden ninguna operación de pinctrl Tegra, porque las operaciones pinmux de Tegra proporcionan gestión de solicitud/liberación de GPIO pero carecen de un hook gpio_set_direction.
La llamada extra aún entra en el núcleo de pinctrl y adquiere pctldev->mutex. Los usuarios compartidos de GPIO pueden llamar a la ruta de dirección mientras mantienen su spinlock por línea, por lo que esta llamada redundante de dirección de pinctrl puede bloquearse (sleep) en un contexto atómico.
Esto fue detectado por nuestra herramienta de análisis estático y luego confirmado mediante revisión manual de tegra_gpio_probe(), las callbacks de dirección GPIO de Tegra y las operaciones pinctrl de Tegra. La ruta revisada tiene una struct gpio_chip predeterminada que no permite bloqueos (non-sleeping), mientras que la callback de dirección aún entra en la ruta del mutex de pinctrl.
Una validación en tiempo real dirigida mantuvo el mismo registro de chip non-sleeping y ejecutó:
gpio_shared_proxy_direction_output() gpiod_direction_output_raw_commit() tegra_gpio_direction_output() pinctrl_gpio_direction_output()
Lockdep informó una advertencia de sleep-in-atomic con el spinlock compartido de GPIO mantenido y las funciones pinctrl_get_device_gpio_range() más tegra_gpio_direction_output() en la pila.
No se debe marcar todo el chip como can_sleep para tapar este problema: can_sleep describe si get()/set() pueden bloquearse, y el acceso a valores Tegra es MMIO. Se eliminan las llamadas redundantes de dirección de pinctrl y se mantiene la participación de pinctrl en la ruta existente de solicitud/liberación.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.