Is CVE-2021-29256 (Arm Mali GPU Kernel Driver Use-After-Free) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2021-29256 to its Known Exploited Vulnerabilities catalogue on 7 July 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Arm Mali GPU Kernel Driver contains a use-after-free vulnerability that may allow a non-privileged user to gain root privilege and/or disclose information.

What active exploitation means for CVE-2021-29256

For this CVE, “being exploited in the wild” means the vulnerability has moved beyond theoretical impact and has been observed well enough for CISA to place it in the Known Exploited Vulnerabilities catalogue. That changes the response priority from routine patch planning to urgent exposure confirmation, remediation, and compromise review.

Because the flaw is in a kernel driver, the practical concern is not only crash risk but privilege gain and information disclosure from a lower-privileged starting point. On systems that include Arm Mali GPU components, the security question is whether the vulnerable driver is present, reachable, and already part of an exploitation path.

When the subject is an actively exploited kernel weakness, treat the driver as part of the attack surface rather than just a compatibility component. Guidance such as CISA Known Exploited Vulnerabilities Catalog helps establish why this moves into urgent remediation territory, while the vulnerability record in the NIST National Vulnerability Database is useful for confirming the identifier and tracking the record as part of broader vulnerability management.

Why this vulnerability is operationally serious

A use-after-free in a kernel driver is serious because kernel memory corruption can turn a local exploit into system-level control. In practical terms, that can enable root privilege, data exposure, or both, depending on how the flaw is triggered and what the attacker can reach on the device.

The issue is most relevant where mobile or embedded platforms depend on the affected graphics stack and where local code execution is already possible through another foothold. The driver may then become the privilege-escalation step that converts partial access into full compromise.

For broader exploitation context, the CVE Program defines the identifier used to track the flaw, and exploitation-prioritisation workflows often pair that record with the FIRST EPSS signal when deciding which issues need immediate operational attention.

How to respond when patching cannot happen immediately

If you cannot remediate right away, the priority is to reduce exposure and preserve evidence. That means identifying where the Mali driver is deployed, limiting the devices or user contexts that can reach it, and checking for signs that a privileged escalation attempt already occurred.

Where available, use compensating controls such as restricting untrusted code execution paths, tightening device-management policy, and increasing telemetry on abnormal crashes, privilege changes, or unexpected driver activity. The objective is not to “wait safely”, but to shrink the window in which an exploitable kernel flaw remains reachable.

NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames the response pattern for KEV-listed issues, and the Vulnerability Management Guide helps anchor triage, exception handling, and verification in a repeatable process. If the device fleet includes mobile endpoints, the Mobile Device Security Guide provides the operational context for scope, enrolment, and policy enforcement.

Risk and Threat Considerations

This CVE is attractive to attackers because kernel drivers sit close to the hardware and can provide a clean path from ordinary user access to full system compromise. Once an exploit is public or repurposed, the main risk is not just execution of the bug itself, but the downstream use of that privilege to evade controls, collect sensitive data, or establish persistence.

Failure mechanism: A use-after-free allows attacker-controlled access to freed kernel memory, which can destabilise memory safety and enable privilege escalation or information disclosure.

Impact: An attacker who can trigger the flaw may gain root-level access, bypass local trust boundaries, and use the compromised device as a pivot point for follow-on activity.

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 OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation requires urgent identification and remediation of exposed flaws.
Recommendation — Prioritise discovery and remediation of KEV-listed vulnerabilities across the device estate.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE response depends on finding affected assets and validating exposure quickly.
	SI-2 — Flaw Remediation	A KEV-listed driver flaw needs prompt correction or mitigation and follow-up verification.
	SI-4 — System Monitoring	Active exploitation warrants heightened monitoring for privilege escalation and compromise signs.
Recommendation — Scan for the vulnerable driver and validate exposure before planning remediation. Apply remediation or compensating controls as soon as the vulnerable component is identified. Increase monitoring for abnormal driver activity, privilege changes, and exploitation indicators.
OWASP ASVS	V15 — Secure Coding and Architecture	Use-after-free defects are a core memory-safety issue that architecture reviews should prevent.
Recommendation — Review memory-safety controls and driver design assumptions that can permit use-after-free defects.

Practitioner Guidance

What to verify: Confirm whether affected devices actually include the Mali kernel driver in the deployed build, and do not assume a platform is safe just because the vulnerable component is not the headline OS version. On endpoint and mobile fleets, inventory accuracy matters more than generic patch compliance.

Decision rule: If the device is exposed and the driver is present, treat remediation as urgent, even if you have not seen abuse yet. If patching must wait, raise monitoring priority and narrow who can execute untrusted code on the affected estate.

Practitioner takeaway: For KEV-listed kernel flaws, the right question is not whether exploitation is possible, but how quickly you can prove exposure, contain blast radius, and rule out earlier compromise.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org