CVE-2025-38521

{"id": "CVE-2025-38521", "cveTags": [], "metrics": {}, "published": "2025-08-16T11:15:45.413", "references": [{"url": "https://git.kernel.org/stable/c/9f852d301f642223c4798f3c13ba15e91165d078", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d38376b3ee48d073c64e75e150510d7e6b4b04f7", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e066cc6e0f094ca2120f1928d126d56f686cd73e", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: Fix kernel crash when hard resetting the GPU\n\nThe GPU hard reset sequence calls pm_runtime_force_suspend() and\npm_runtime_force_resume(), which according to their documentation should\nonly be used during system-wide PM transitions to sleep states.\n\nThe main issue though is that depending on some internal runtime PM\nstate as seen by pm_runtime_force_suspend() (whether the usage count is\n<= 1), pm_runtime_force_resume() might not resume the device unless\nneeded. If that happens, the runtime PM resume callback\npvr_power_device_resume() is not called, the GPU clocks are not\nre-enabled, and the kernel crashes on the next attempt to access GPU\nregisters as part of the power-on sequence.\n\nReplace calls to pm_runtime_force_suspend() and\npm_runtime_force_resume() with direct calls to the driver's runtime PM\ncallbacks, pvr_power_device_suspend() and pvr_power_device_resume(),\nto ensure clocks are re-enabled and avoid the kernel crash."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imagination: Se corrige el fallo del kernel al reiniciar la GPU La secuencia de reinicio completo de la GPU llama a pm_runtime_force_suspend() y pm_runtime_force_resume(), que seg\u00fan su documentaci\u00f3n solo se deben usar durante las transiciones de PM de todo el sistema a estados de suspensi\u00f3n. Sin embargo, el problema principal es que, dependiendo de alg\u00fan estado interno de PM en tiempo de ejecuci\u00f3n, como se ve en pm_runtime_force_suspend() (si el recuento de uso es &lt;= 1), pm_runtime_force_resume() podr\u00eda no reanudar el dispositivo a menos que sea necesario. Si eso sucede, no se llama a la devoluci\u00f3n de llamada de reanudaci\u00f3n de PM en tiempo de ejecuci\u00f3n pvr_power_device_resume(), no se vuelven a habilitar los relojes de la GPU y el kernel se bloquea en el siguiente intento de acceder a los registros de la GPU como parte de la secuencia de encendido. Reemplace las llamadas a pm_runtime_force_suspend() y pm_runtime_force_resume() con llamadas directas a las devoluciones de llamadas PM de tiempo de ejecuci\u00f3n del controlador, pvr_power_device_suspend() y pvr_power_device_resume(), para garantizar que los relojes se vuelvan a habilitar y evitar el bloqueo del kernel."}], "lastModified": "2025-08-18T20:16:28.750", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}