CVE-2021-47447

What it actually does

Incorrect error handling in a3xx_gpu_init returns positive value 1 on failure instead of negative errno, causing an Oops in the caller; additionally the ret != -ENODATA check is ineffective because ret was already overwritten to 1.

Why it matters to the business

Linux systems using affected Adreno a3xx GPUs may experience unexpected kernel crashes during graphics initialization, leading to downtime and potential loss of availability on servers, desktops, or embedded devices.

How an attack unfolds

An attacker with local access triggers the GPU driver initialization error path (for example via specific hardware states or module load failures) so that the positive return value propagates and dereferences an invalid pointer, resulting in a kernel oops.

How to fix it

Update the Linux kernel to a version containing the fix for error handling in a3xx_gpu_init; apply the upstream patch that returns proper negative error codes and preserves the ENODATA check.

How to confirm the fix worked

Inspect kernel source for a3xx_gpu_init to confirm negative errno returns on error paths and that the ret != -ENODATA comparison remains valid; boot test systems with the msm driver and verify absence of Oops on simulated failures.

Typical attack path

1. Obtain local access to a system with msm DRM driver for a3xx GPU
2. Force an error condition during a3xx_gpu_init execution
3. Observe positive 1 return instead of negative errno
4. Trigger Oops in the calling code path

How to detect it

Search kernel logs and crash dumps for Oops messages originating from drm/msm/a3xx code paths or unexpected positive return values during GPU initialization.

What your security team should do

• Prioritize kernel updates on any systems exposing the msm DRM driver
• Monitor kernel oops reports for drm/msm signatures even though EPSS remains low
• Apply the fix during the next maintenance window given the 880-day publication age and lack of KEV listing