CVE-2024-38390

What it actually does

Null pointer dereference in msm_gpu_cleanup when a6xx_destroy is invoked prior to adreno_gpu_init completing, because gpu->pdev is never assigned.

Why it matters to the business

Kernel panic or denial of service on systems using the affected MSM A6xx GPU driver, potentially disrupting graphics workloads or device operation; no widespread exploitation observed despite long availability.

How an attack unfolds

An attacker with local access triggers the speedbin failure path during GPU initialization, causing early cleanup that dereferences an uninitialized pointer; no named threat actors have been observed exploiting this path.

How to fix it

Update the Linux kernel to commit 247849eeb3fd88f8990ed73e33af70d5c10f9aec or later; rebuild and deploy the fixed kernel image on all affected systems.

How to confirm the fix worked

Confirm the running kernel contains commit 247849eeb3fd88f8990ed73e33af70d5c10f9aec; attempt to reproduce the original speedbin-failure initialization sequence and verify no null dereference occurs.

Typical attack path

1. Obtain local code execution on an affected Linux or Android device
2. Force the a6xx speedbin configuration to fail during driver probe
3. Trigger a6xx_destroy before adreno_gpu_init completes
4. Reach msm_gpu_cleanup which dereferences the null pdev pointer

How to detect it

Review kernel logs for null pointer dereference oops in msm_gpu_cleanup or a6xx_destroy around GPU probe time; no specific post-exploitation artifacts are known.

What your security team should do

• Prioritize kernel upgrade on all devices using MSM A6xx graphics hardware
• Monitor vendor kernel update channels for backported fixes
• Test graphics driver stability after patching under simulated initialization-failure conditions