fkie_cve-2025-38354
Vulnerability from fkie_nvd
Published
2025-07-25 13:15
Modified
2025-07-25 15:29
Severity ?
Summary
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/
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1847ea44e3bdf7da8ff4158bc01b43a2e46394bd
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7946a10f8da75abc494e4bb80243e153e93e459a
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a6f673cc9488fd722c601fe020601dba14db21b2
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ae2015b0dbc0eea7aaf022194371f451f784d994
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b71717735be48d7743a34897e9e44a0b53e30c0e
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/gpu: Fix crash when throttling GPU immediately during boot\n\nThere is a small chance that the GPU is already hot during boot. In that\ncase, the call to of_devfreq_cooling_register() will immediately try to\napply devfreq cooling, as seen in the following crash:\n\n  Unable to handle kernel paging request at virtual address 0000000000014110\n  pc : a6xx_gpu_busy+0x1c/0x58 [msm]\n  lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]\n  Call trace:\n   a6xx_gpu_busy+0x1c/0x58 [msm] (P)\n   devfreq_simple_ondemand_func+0x3c/0x150\n   devfreq_update_target+0x44/0xd8\n   qos_max_notifier_call+0x30/0x84\n   blocking_notifier_call_chain+0x6c/0xa0\n   pm_qos_update_target+0xd0/0x110\n   freq_qos_apply+0x3c/0x74\n   apply_constraint+0x88/0x148\n   __dev_pm_qos_update_request+0x7c/0xcc\n   dev_pm_qos_update_request+0x38/0x5c\n   devfreq_cooling_set_cur_state+0x98/0xf0\n   __thermal_cdev_update+0x64/0xb4\n   thermal_cdev_update+0x4c/0x58\n   step_wise_manage+0x1f0/0x318\n   __thermal_zone_device_update+0x278/0x424\n   __thermal_cooling_device_register+0x2bc/0x308\n   thermal_of_cooling_device_register+0x10/0x1c\n   of_devfreq_cooling_register_power+0x240/0x2bc\n   of_devfreq_cooling_register+0x14/0x20\n   msm_devfreq_init+0xc4/0x1a0 [msm]\n   msm_gpu_init+0x304/0x574 [msm]\n   adreno_gpu_init+0x1c4/0x2e0 [msm]\n   a6xx_gpu_init+0x5c8/0x9c8 [msm]\n   adreno_bind+0x2a8/0x33c [msm]\n   ...\n\nAt this point we haven\u0027t initialized the GMU at all yet, so we cannot read\nthe GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before\nin commit 6694482a70e9 (\"drm/msm: Avoid unclocked GMU register access in\n6xx gpu_busy\"): msm_devfreq_init() does call devfreq_suspend_device(), but\nunlike msm_devfreq_suspend(), it doesn\u0027t set the df-\u003esuspended flag\naccordingly. This means the df-\u003esuspended flag does not match the actual\ndevfreq state after initialization and msm_devfreq_get_dev_status() will\nend up accessing GMU registers, causing the crash.\n\nFix this by setting df-\u003esuspended correctly during initialization.\n\nPatchwork: https://patchwork.freedesktop.org/patch/650772/"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/gpu: se corrige el fallo que se produce al limitar la GPU inmediatamente durante el arranque. Existe una peque\u00f1a posibilidad de que la GPU ya est\u00e9 caliente durante el arranque. En ese caso, la llamada a of_devfreq_cooling_register() intentar\u00e1 inmediatamente aplicar el enfriamiento devfreq, como se ve en el siguiente fallo: No se puede manejar la solicitud de paginaci\u00f3n del kernel en la direcci\u00f3n virtual 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] ... En este punto, a\u00fan no hemos inicializado la GMU en absoluto, por lo que no podemos leer los registros de la GMU dentro de a6xx_gpu_busy(). Un problema similar se solucion\u00f3 previamente en el commit 6694482a70e9 (\"drm/msm: Evitar el acceso a registros de GMU sin reloj en 6xx gpu_busy\"): msm_devfreq_init() llama a devfreq_suspend_device(), pero a diferencia de msm_devfreq_suspend(), no establece el indicador df-\u0026gt;suspended como corresponde. Esto significa que el indicador df-\u0026gt;suspended no coincide con el estado real de devfreq tras la inicializaci\u00f3n y msm_devfreq_get_dev_status() acceder\u00e1 a los registros de GMU, lo que provocar\u00e1 el bloqueo. Para solucionarlo, configure df-\u0026gt;suspended correctamente durante la inicializaci\u00f3n. Patchwork: https://patchwork.freedesktop.org/patch/650772/"
    }
  ],
  "id": "CVE-2025-38354",
  "lastModified": "2025-07-25T15:29:19.837",
  "metrics": {},
  "published": "2025-07-25T13:15:24.123",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1847ea44e3bdf7da8ff4158bc01b43a2e46394bd"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7946a10f8da75abc494e4bb80243e153e93e459a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a6f673cc9488fd722c601fe020601dba14db21b2"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ae2015b0dbc0eea7aaf022194371f451f784d994"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b71717735be48d7743a34897e9e44a0b53e30c0e"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.