CVE-2025-71299 in Linux
Resumen
por VulDB • 2026-05-09
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
spi: cadence-quadspi: Analizar el DT (Device Tree) para las memorias flash junto con el resto del análisis del DT
La reciente refactorización del momento en que se habilita el PM (Power Management) en tiempo de ejecución, realizada en el commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Habilitar pm runtime más temprano para evitar desequilibrios"), hizo evidente que, al realizar una pm_runtime_disable() en las rutas de error de probe(), podemos desencadenar una desactivación en tiempo de ejecución que, a su vez, resulta en deshabilitaciones duplicadas de los relojes. Esto es particularmente probable cuando falta o está corrupta la descripción del DT para las memorias flash conectadas al controlador.
Temprano en la función probe(), realizamos un pm_runtime_get_noresume() ya que la función probe() deja el dispositivo en un estado de encendido, pero en la ruta de error no podemos asumir que el PM está habilitado, por lo que también deshabilitamos manualmente todo, incluidos los relojes. Esto significa que cuando el PM en tiempo de ejecución está activo, tanto este como la función probe() liberan la misma referencia al reloj principal del IP, desencadenando advertencias desde el subsistema de relojes:
[ 8.693719] clk:75:7 ya deshabilitado
[ 8.693791] ADVERTENCIA: CPU: 1 PID: 185 en /usr/src/kernel/drivers/clk/clk.c:1188 clk_core_disable+0xa0/0xb
... [ 8.694261] clk_core_disable+0xa0/0xb4 (P)
[ 8.694272] clk_disable+0x38/0x60
[ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi]
[ 8.694309] platform_probe+0x5c/0xa4
Abordar este problema adecuadamente se complica por el hecho de que no sabemos si el PM en tiempo de ejecución está activo, por lo que no podemos determinar si deshabilitará los relojes o no. Sin embargo, podemos evitar el problema para las descripciones de las memorias flash moviendo su análisis al momento en que analizamos las propiedades del controlador, lo que también nos ahorra realizar una serie de configuraciones que nunca se utilizarán, así que hagámoslo.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.