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

Yes. CISA added CVE-2022-38181 to its Known Exploited Vulnerabilities catalogue on 30 March 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 “being exploited in the wild” means for this CVE

For this vulnerability, the practical question is not whether the flaw exists, but whether it has moved from a theoretical issue to one that defenders should treat as actively targeted. CISA’s KEV listing is the strongest operational signal here: it indicates confirmed exploitation observed by trusted sources, which should move the issue into urgent triage rather than routine backlog treatment.

That matters because a kernel driver use-after-free changes the blast radius. A flaw in graphics or driver code is not just a crash risk, it can become a path to privilege escalation, local compromise, or information disclosure on systems that allow the affected driver to run.

Why this class of flaw is high priority

Use-after-free bugs in kernel space are dangerous because they involve memory objects whose lifetime has already ended, yet the code later reuses them. In a driver, that can produce privilege boundary violations inside the operating system itself, where an unprivileged user may be able to influence memory state, trigger unsafe execution paths, or expose sensitive data.

For defenders, the key judgment is that exploitation does not require a public ransomware tie-in to be severe. Once a kernel-level issue is known to be exploited, any system with the vulnerable component becomes a candidate for opportunistic abuse, especially where local access is already available or where another foothold can be turned into escalation.

How to triage exposure and respond

Start by confirming whether the Arm Mali GPU Kernel Driver is present in your fleet and whether the vulnerable code path is actually reachable on those systems. Mobile devices, embedded endpoints and managed fleets often have uneven driver baselines, so inventory and version validation matter more than assuming the operating system alone tells the whole story.

If the platform is exposed, prioritize the vendor’s remediation guidance and CISA KEV instructions over general patch scheduling. When a patch cannot be applied immediately, treat the device as higher risk, reduce unnecessary local access, and narrow the set of users or applications that can interact with the graphics stack where possible.

If you need a reference point for how to triage and sequence this work, Zero-Day and Exploited Vulnerabilities Guide covers the operational pattern for prioritizing KEV-listed issues, while Vulnerability Management Guide is useful for exception handling, verification and remediation tracking.

Risk and Threat Considerations

Actively exploited kernel-driver flaws are attractive because they can turn ordinary user-level access into system-level compromise, and they can do so on a large number of endpoints if the vulnerable driver is broadly deployed. The risk is amplified when the driver is part of a platform component that teams do not monitor as closely as userland software.

Failure mechanism: A use-after-free in kernel memory management can let an attacker manipulate freed objects, potentially redirect execution or corrupt state in a privileged context.

Impact: Successful exploitation can lead to root-level privilege, data exposure, device compromise, and a stronger foothold 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 makes prioritized remediation and exposure tracking essential.
Recommendation — Prioritize, remediate, and verify KEV-listed exposure across the fleet.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The CVE requires timely remediation and verification of applied fixes.
	RA-5 — Vulnerability Monitoring and Scanning	You need inventory and scan coverage to confirm whether the vulnerable driver is present.
	AU-6 — Audit Review, Analysis, and Reporting	Compromise review requires log analysis after possible exploitation.
Recommendation — Patch or mitigate the driver flaw and confirm remediation evidence. Scan assets to identify systems still exposed to the vulnerable driver. Review logs and alerts for signs of privilege escalation or kernel abuse.
OWASP ASVS	V15 — Secure Coding and Architecture	The flaw is a memory-safety failure in kernel/driver code.
Recommendation — Treat lifetime and memory-safety defects as high-severity architecture issues.

Practitioner Guidance

What to verify: Confirm whether any managed device actually loads the affected Arm Mali GPU Kernel Driver and whether the vendor fix or mitigation has been applied. Do not rely on OS patch status alone if driver updates are distributed separately or through firmware channels.

Decision rule: If the driver is present and the endpoint is still unremediated, treat it as an urgent security exception until it is patched or otherwise brought out of exposure. If the device has elevated user access, shared administration, or sensitive local data, raise the priority further.

Practitioner takeaway: A KEV-listed kernel bug should be handled as confirmed exploitation pressure, not as a speculative vulnerability, so the response should focus on exposure confirmation, remediation, and compromise checks rather than waiting for additional reporting.