CVE-2021-28663: Arm Mali Graphics Processing Unit (GPU) Use-After-Free Vulnerability

CVE-2021-28663 is a use-after-free vulnerability in the Arm Mali Graphics Processing Unit (GPU) kernel driver. A non-privileged local user who can interact with the driver may perform improper operations on GPU memory, potentially escalating to root privileges and/or disclosing information. Because the flaw sits in a widely deployed GPU kernel component, it matters for any environment running Arm Mali GPUs—especially Android devices, embedded systems, and other platforms that expose the driver to untrusted or multi-user code.

Defenders should treat this as a local privilege-escalation and information-disclosure risk in the kernel graphics stack. Confirm exact affected products, versions, and fixes directly against the vendor advisory; do not rely on secondary summaries alone.

How it works

The weakness is CWE-416 (use-after-free). In a use-after-free condition, the driver frees a memory object related to GPU operations but later continues to use a stale reference to that object. An attacker who can influence allocation, free, and reuse patterns may cause the kernel to operate on memory that now holds attacker-controlled data or that belongs to another context.

According to the CISA summary, a non-privileged user can make improper operations on GPU memory. Successful abuse may allow elevation to root and/or leakage of kernel or process memory contents. Public detail on exact trigger sequences, ioctls, or heap grooming steps is limited; treat any exploit claims as unconfirmed until verified against the vendor write-up. The practical impact is local: the attacker already needs code execution or an interface that reaches the Mali kernel driver on the target system.

Am I affected? How to find it in your systems

Arm Mali GPUs appear in many mobile SoCs, tablets, set-top boxes, automotive and industrial boards, and some server or edge platforms that use Arm graphics. The vulnerable component is the GPU kernel driver, not the userspace libraries alone.

• Inventory devices and images that ship an Arm Mali GPU and its kernel driver (common on Android and custom Linux kernels). Check SoC documentation, device trees, kernel config, and loaded modules for Mali-related drivers.
• Identify kernel and driver package versions on each platform; map them to the versions listed in the Arm or device-vendor advisory. If your OEM or carrier supplies the kernel, obtain their security bulletin rather than assuming upstream status.
• On managed fleets, query asset management, MDM, or SBOM data for Mali GPU presence and driver package names. On Linux, inspect loaded modules and kernel logs for Mali driver initialization.
• Telemetry signs of exploitation are not uniquely documented for this CVE. Watch for unexpected local privilege escalations, crashes or oopses in the GPU driver, anomalous GPU memory operations from unprivileged processes, and sudden root or capability gains on devices that expose the driver. Correlate with process ancestry and recent untrusted code execution.

When in doubt, assume potential exposure until the vendor advisory confirms your build is patched or not affected.

How to remediate

Patch first. Apply the updates provided by Arm or by your device/OS vendor exactly as instructed in their advisory. CISA’s required action is to apply updates per vendor instructions. Rebuild or redeploy kernels and driver packages through your normal secure update pipeline; verify the fixed driver version is running after reboot.

• Prioritize internet-facing or multi-user systems, developer devices, and any host that runs untrusted local code with access to the GPU interface.
• After patching, confirm the new driver is loaded and that old packages are removed from images and update mirrors.
• Hardening for this class: keep the attack surface small by limiting which processes can open GPU device nodes, apply least privilege and SELinux/AppArmor (or equivalent) policies that confine untrusted apps, and avoid granting unnecessary graphics or render privileges to low-trust workloads.
• Maintain current kernel and vendor security baselines so subsequent Mali or graphics fixes are not delayed.

If you can't patch immediately

Use compensating controls until the vendor update can be deployed.

• Segment and isolate: keep devices that still run the vulnerable driver off high-value networks where possible; restrict lateral movement paths from those hosts.
• Reduce local attack surface: disable or unload the Mali driver only if the workload truly does not need GPU acceleration and the vendor supports that configuration; otherwise limit which users and containers can access /dev GPU nodes.
• Policy controls: tighten MAC policies, drop unnecessary capabilities, and prevent untrusted apps from reaching the GPU interface.
• Monitoring: alert on GPU driver crashes, unexpected root escalations, and anomalous access to Mali device nodes. Increase logging verbosity for the graphics stack if operationally feasible.
• Virtual patching / WAF is generally not applicable to a local kernel GPU driver flaw; focus on host controls and access restriction rather than network signatures.

These measures lower likelihood and impact but do not replace the vendor fix.

If your data may have been exposed

Actively exploited local privilege-escalation flaws can lead to full device compromise and subsequent data theft. Known ransomware use is not documented for this CVE. If you suspect compromise, isolate the device, preserve volatile evidence, rotate credentials that may have been present on the system, and follow your incident-response process. As a further check, you can run a free exposure scan of your email addresses against known breach datasets to see whether associated accounts appear in prior public breaches.