CVE-2025-71299 in Linux
Sumário
de VulDB • 11/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
spi: cadence-quadspi: Analisar DT para flashes com o restante da análise DT
A recente refatoração de onde o PM de tempo de execução (runtime PM) é habilitado, feita no commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance"), tornou evidente que, ao realizarmos uma pm_runtime_disable() nos caminhos de erro de probe(), podemos acionar uma desativação de tempo de execução que, por sua vez, resulta em desativações duplicadas de clock. Isso é particularmente provável de acontecer quando há uma descrição DT ausente ou incorreta para os flashes conectados ao controlador.
No início da função probe, realizamos um pm_runtime_get_noresume(), já que a função probe deixa o dispositivo em estado de energia ligada, mas no caminho de erro não podemos assumir que o PM está habilitado, portanto, desativamos manualmente tudo, incluindo os clocks. Isso significa que, quando o PM de tempo de execução está ativo, tanto ele quanto a função probe liberam a mesma referência para o clock principal do IP, acionando avisos do subsistema de clock:
[ 8.693719] clk:75:7 already disabled
[ 8.693791] WARNING: CPU: 1 PID: 185 at /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
Lidar adequadamente com este problema é complicado pelo fato de não sabermos se o PM de tempo de execução está ativo, portanto, não podemos dizer se ele desativará os clocks ou não. No entanto, podemos contornar o problema para as descrições de flash movendo sua análise para quando analisamos as propriedades do controlador, o que também nos poupa de realizar uma série de configurações que nunca serão usadas, então vamos fazer isso.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.