CVE-2021-47535

What it actually does

Out-of-bounds write due to insufficient kernel memory allocation for an expanded set of GMU registers in a6xx_get_gmu_registers, resulting in slab corruption during GPU crash state capture on Adreno hardware.

Why it matters to the business

Systems using affected Adreno a6xx GPUs may experience kernel instability or crashes during graphics error recovery, potentially disrupting workloads on Linux-based devices and increasing operational downtime risk.

How an attack unfolds

An attacker triggers GPU fault conditions that invoke msm_gpu_crashstate_capture and a6xx_gpu_state_get, causing the undersized allocation to be exceeded when writing additional register sets and leading to memory corruption.

How to fix it

Update to a Linux kernel version containing the fix for the allocation size in a6xx_get_gmu_registers; apply vendor backports if using older LTS branches.

How to confirm the fix worked

Confirm kernel source contains updated kzalloc or array sizing matching the three register sets in a6xx_get_gmu_registers; recompile and test crash state capture on a6xx hardware without KASAN reports.

Typical attack path

1. Trigger graphics or compute workload that induces GPU fault on a6xx hardware
2. Invoke crash state capture path via recover_worker or equivalent
3. Execute a6xx_gpu_state_get which calls a6xx_get_gmu_registers with insufficient buffer
4. Write beyond allocated slab memory during register reads

How to detect it

Search kernel logs and dmesg for KASAN slab-out-of-bounds reports referencing _a6xx_get_gmu_registers or a6xx_gpu_state_get; inspect crash dumps from msm_gpu_crashstate_capture on affected hardware.

What your security team should do

• Prioritize kernel upgrades on any systems exposing Adreno a6xx GPUs
• Monitor for GPU-related kernel oops or KASAN reports in production logs
• Test graphics recovery paths in staging environments before broad deployment