CVE-2025-38354

Medium

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/

Package Linux Kernel
Published 2025-07-25
Last modified 2025-12-16
CVSS version 3.1
Patch available
Yes

CVSS 3.1 score

5.5

out of 10
Medium
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
High
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected versions

Linux kernel versions 5.18.18, 5.19.2, 6.0 and later are affected. Fixed in 6.1.143, 6.6.96, 6.12.36, 6.15.5, 6.16 and their respective stable series.

Affected from
≥ 5.18.18 ≥ 5.19.2 ≥ 6.0
Fixed in
✓ 6.1.143 6.1.x ✓ 6.6.96 6.6.x ✓ 6.12.36 6.12.x ✓ 6.15.5 6.15.x ✓ 6.16

References

The following references provide additional information about CVE-2025-38354 including vendor advisories, patch commits, exploit details, and third-party analysis. Links are sourced from the NIST NVD database.

5 patch commits total View all on NVD

Frequently asked questions

  • What is CVE-2025-38354?

    CVE-2025-38354 is a Medium severity Linux kernel vulnerability with a CVSS score of 5.5 out of 10 . It affects Linux kernel versions from 5.18.18 onward and has been patched in 6.1.143, 6.6.96, 6.12.36 and others. CVE-2025-38354 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.

  • What is the CVSS score for CVE-2025-38354?

    CVE-2025-38354 has a CVSS score of 5.5 out of 10, rated Medium severity (CVSS 3.1). The vector string is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H .

  • Is there a patch available for CVE-2025-38354?

    Yes — CVE-2025-38354 has been patched. Fixed versions include 6.1.143, 6.6.96, 6.12.36 and others. If you are running Linux kernel 5.18.18 or later up to the fix versions, apply the relevant patch for your kernel branch.

  • Is CVE-2025-38354 actively exploited?

    No — CVE-2025-38354 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

Back to
All CVEs
View on
NVD / NIST