CVE-2025-71299

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: cadence-quadspi: Parse DT for flashes with the rest of the DT parsing<br /> <br /> The recent refactoring of where runtime PM is enabled done in commit<br /> f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to<br /> avoid imbalance") made the fact that when we do a pm_runtime_disable()<br /> in the error paths of probe() we can trigger a runtime disable which in<br /> turn results in duplicate clock disables. This is particularly likely<br /> to happen when there is missing or broken DT description for the flashes<br /> attached to the controller.<br /> <br /> Early on in the probe function we do a pm_runtime_get_noresume() since<br /> the probe function leaves the device in a powered up state but in the<br /> error path we can&amp;#39;t assume that PM is enabled so we also manually<br /> disable everything, including clocks. This means that when runtime PM is<br /> active both it and the probe function release the same reference to the<br /> main clock for the IP, triggering warnings from the clock subsystem:<br /> <br /> [ 8.693719] clk:75:7 already disabled<br /> [ 8.693791] WARNING: CPU: 1 PID: 185 at /usr/src/kernel/drivers/clk/clk.c:1188 clk_core_disable+0xa0/0xb<br /> ...<br /> [ 8.694261] clk_core_disable+0xa0/0xb4 (P)<br /> [ 8.694272] clk_disable+0x38/0x60<br /> [ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi]<br /> [ 8.694309] platform_probe+0x5c/0xa4<br /> <br /> Dealing with this issue properly is complicated by the fact that we<br /> don&amp;#39;t know if runtime PM is active so can&amp;#39;t tell if it will disable the<br /> clocks or not. We can, however, sidestep the issue for the flash<br /> descriptions by moving their parsing to when we parse the controller<br /> properties which also save us doing a bunch of setup which can never be<br /> used so let&amp;#39;s do that.