CVE-2025-38354

In the Linux kernel, the following vulnerability has been resolved:

drm/msm/gpu: Fix crash when throttling GPU immediately during boot

There is a small chance that the GPU is already hot during boot. In that case, the call to ofdevfreqcooling_register() will immediately try to apply devfreq cooling, as seen in the following crash:

Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xxgpubusy+0x1c/0x58 [msm] lr : msmdevfreqgetdevstatus+0xbc/0x140 [msm] Call trace: a6xxgpubusy+0x1c/0x58 [msm] (P) devfreqsimpleondemandfunc+0x3c/0x150 devfrequpdatetarget+0x44/0xd8 qosmaxnotifiercall+0x30/0x84 blockingnotifiercallchain+0x6c/0xa0 pmqosupdatetarget+0xd0/0x110 freqqosapply+0x3c/0x74 apply_constraint+0x88/0x148 __devpmqosupdaterequest+0x7c/0xcc devpmqosupdaterequest+0x38/0x5c devfreqcoolingsetcurstate+0x98/0xf0 __thermalcdevupdate+0x64/0xb4 thermalcdevupdate+0x4c/0x58 stepwisemanage+0x1f0/0x318 __thermalzonedevice_update+0x278/0x424 _thermalcoolingdeviceregister+0x2bc/0x308 thermalofcoolingdeviceregister+0x10/0x1c ofdevfreqcoolingregisterpower+0x240/0x2bc ofdevfreqcoolingregister+0x14/0x20 msmdevfreqinit+0xc4/0x1a0 [msm] msmgpuinit+0x304/0x574 [msm] adrenogpuinit+0x1c4/0x2e0 [msm] a6xxgpuinit+0x5c8/0x9c8 [msm] adrenobind+0x2a8/0x33c [msm] ...

At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xxgpubusy(). A similar issue was fixed before in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpubusy"): msmdevfreqinit() does call devfreqsuspenddevice(), but unlike msmdevfreqsuspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msmdevfreqgetdev_status() will end up accessing GMU registers, causing the crash.

Fix this by setting df->suspended correctly during initialization.

Patchwork: https://patchwork.freedesktop.org/patch/650772/