CVE-2025-38354

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

MEDIUM

5.5

CVSS Score

Published: July 25, 2025 at 12:47 PM UTC

Updated: June 17, 2026 at 09:16 AM UTC

2 products affected across 2 vendorsLinux KernelDebian Linux

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available

Start Free Sign In

Severity

MEDIUM5.5

Exploit prediction

EPSS 0.2%

Description

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 of_devfreq_cooling_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 : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ... At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), 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 msm_devfreq_get_dev_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/

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

Debian Linux · Debiandrupal

95%

11.0

Linux Kernel · Linux

95%

v ≥ 5.18.18v ≥ 5.19.25.18.18 ≤ v < 5.195.19.2 ≤ v < 5.205.19.2 ≤ v < 6.1.1436.0 ≤ v < 6.1.1436.0 ≤ v < 6.12.366.0 ≤ v < 6.15.56.0 ≤ v < 6.166.0 ≤ v < 6.6.966.13 ≤ v < 6.15.56.2 ≤ v < 6.6.966.7 ≤ v < 6.12.361f6c087dd6a915f1c3471f0f0f696847fc8c592f5.18.18 5.19.2 6.06694482a70e9536efbf2ac233cbf0c302d6e2dae9c8b3f05fb18fba12f3fca80a378c9b8f3d04cd6

Vendor states this is fixed in 1847ea44e3bdf7da8ff4158bc01b43a2e46394bd (fixed)

Vendor states this is fixed in 7946a10f8da75abc494e4bb80243e153e93e459a (fixed)

Vendor states this is fixed in a6f673cc9488fd722c601fe020601dba14db21b2 (fixed)

Vendor states this is fixed in ae2015b0dbc0eea7aaf022194371f451f784d994 (fixed)

Vendor states this is fixed in b71717735be48d7743a34897e9e44a0b53e30c0e (fixed)

Affected range stops below 5.19, so it looks safe — our inference, not a vendor statement

Affected range stops below 5.20, so it looks safe — our inference, not a vendor statement

Vendor states this is fixed in 6.0 (unaffected)

Vendor states this is fixed in 6.1.143 (unaffected)

Vendor states this is fixed in 6.12.36 (unaffected)

Vendor states this is fixed in 6.15.5 (unaffected)

Vendor states this is fixed in 6.16 (unaffected)