How do you patch or mitigate CVE-2021-28663 (Arm Mali Graphics Processing Unit (GPU) Use-After-Free)?

CISA’s required action for CVE-2021-28663 is to apply updates per vendor instructions. In practice, find every instance of Arm Mali Graphics Processing Unit (GPU) in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What CVE-2021-28663 Means for Arm Mali GPU Exposure

CVE-2021-28663 is a use-after-free in Arm Mali Graphics Processing Unit software, so the practical question is not only whether a device is vulnerable, but whether the vulnerable driver is actually present and reachable in your fleet. Treat it like any other exploited platform flaw: inventory first, then confirm which devices use the affected graphics stack, and then decide whether you can patch, mitigate, or isolate the system quickly enough to stay safe.

Because the flaw was exploited in the wild, exposure is more than a theoretical compatibility issue. If the vulnerable GPU component sits on a user-facing endpoint, a browser, app sandbox, or shared workstation, the risk is that an attacker can turn an otherwise routine software path into a reliable foothold for code execution or privilege escalation.

A useful first step is to identify every operating system build, device class, and vendor image that includes Arm Mali GPU components, then compare them with the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog. That is the fastest way to separate systems that need immediate action from systems that are only adjacent to the affected product family.

How to Patch or Mitigate It Safely

The preferred fix is the vendor security update or documented mitigation, applied exactly as the vendor instructs. For mobile devices, embedded systems, and managed endpoints, that usually means aligning the patch with the device-management process, verifying that the update actually installed, and confirming that the graphics driver version changed on the affected asset rather than assuming the update was applied globally.

If patching is delayed, reduce exposure rather than waiting on a perfect fix. Removing internet exposure, restricting remote access, narrowing which users can reach the device, or taking the product out of service are all valid compensating actions when the vulnerable GPU stack cannot be remediated immediately. For systems that must remain online, the goal is to reduce reachable attack surface until the update window opens.

For fleets with multiple hardware generations, do not assume one mitigation fits all. Some systems may only accept a vendor firmware or operating-system bundle, while others may need a temporary operational change, such as disabling the exposed service path or moving the device behind a management boundary until the repair is complete.

Checking for Prior Exploitation and Recovery

Because this flaw was used in the wild, patching alone is not enough if the device may already have been compromised. Review endpoint, operating system, and application logs for unusual crashes, unexpected GPU driver faults, privilege changes, suspicious child processes, and post-exploitation activity around the time the vulnerability may have been reachable.

If you find evidence of exploitation, treat the issue as a compromise response problem, not just a patching problem. That means isolating the device, preserving logs and forensic data, validating whether credentials, tokens, or sessions were exposed through the affected system, and deciding whether reimaging or full rebuild is safer than incremental cleanup.

Risk and Threat Considerations

Use-after-free flaws are attractive because they can convert a memory-safety bug into code execution or privilege escalation when the vulnerable component is exposed through a reachable graphics path. In a GPU stack, that makes the impact wider than the graphics layer itself, especially on shared or internet-reachable endpoints.

Failure mechanism: The attacker triggers the freed-memory condition through the graphics driver path, then uses the resulting memory corruption to gain control of execution or destabilize the process boundary.

Impact: Depending on the device and surrounding controls, the outcome can range from crash and denial of service to system compromise, persistence, or follow-on access to local data and credentials.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The issue requires finding, patching, and verifying exposed vulnerable assets.
Recommendation — Prioritise, patch, and verify all exposed Arm Mali assets in your vulnerability workflow.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires vendor updates, mitigations, and remediation tracking.
	RA-5 — Vulnerability Monitoring and Scanning	Confirm where the vulnerable GPU stack exists before remediation and after patching.
	AU-6 — Audit Record Review, Analysis, and Reporting	The answer calls for log review to detect earlier exploitation.
Recommendation — Apply flaw remediation promptly and track compensating mitigations until fixed. Scan and inventory affected devices, then recheck to confirm remediation. Review relevant logs for signs of prior exploitation and escalate confirmed compromise.
NIST CSF 2.0	PR.IP-12 — Vulnerability management is performed	The subject is a real-world vulnerability that must be managed through remediation and verification.
	DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events	Exploitation checks depend on monitoring for suspicious activity and compromise indicators.
Recommendation — Operate a vulnerability management process that drives patching and exception handling. Monitor for exploitation indicators and investigate anomalies tied to the affected devices.

Practitioner Guidance

What to prioritise: Patch internet-facing, user-facing, and high-trust devices first, because those are the systems most likely to turn an exploitable driver bug into a practical intrusion path. Where patch deployment is staged, put affected devices into a temporary containment posture before you wait for the next maintenance window.

What to verify: Confirm the exact vendor build on each device, not just the operating-system family, and verify that the installed package or firmware actually matches the vendor fix. If a device cannot be verified cleanly, treat it as still exposed until proven otherwise.

Practitioner takeaway: For an exploited platform flaw, speed matters, but verification matters just as much, because an unverified patch or a still-reachable device is operationally the same as an unpatched one.