CVE-2022-22706

What it actually does

This is a local privilege-escalation memory corruption issue in the Arm Mali GPU kernel driver. A low-privileged local user or process can abuse the driver to obtain write access to memory pages that should be read-only. Because the affected component runs in kernel context, successful exploitation can allow modification of kernel memory, bypass of operating-system security boundaries, arbitrary code execution with elevated privileges, and full compromise of confidentiality, integrity, and availability on the affected device. Affected driver branches include Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, and Valhall r19p0 through r35p0.

Why it matters to the business

An attacker who can run code on an affected device can potentially take full control of it, bypass application sandboxing, steal sensitive data, disable security controls, install persistent malware, or use the device as a foothold for further activity. The issue is listed in CISA KEV with a remediation due date of 2023-04-20 and is marked as actively exploited in the wild, so affected mobile, embedded, and Linux-based products using vulnerable Arm Mali GPU drivers should be treated as high-priority even though the flaw is local rather than directly network-exploitable.

How an attack unfolds

Exploitation typically starts after the attacker obtains local code execution, such as through a malicious application, a chained browser or messaging exploit, an abused sideloading path, physical access with shell access, or compromise of another local process. The attacker then interacts with the Mali GPU kernel driver, commonly through exposed GPU device interfaces and driver ioctls, to trigger the condition that permits writes to read-only memory pages. By carefully shaping memory allocations and driver operations, the attacker can corrupt privileged kernel state, such as credentials, security policy state, function pointers, or page-table-related structures. Once kernel memory is modified, the attacker can escalate from an unprivileged context to root or equivalent kernel-level control, disable protections, access data belonging to other applications or users, and deploy additional payloads. Public exploitation has been observed in the wild, and the KEV listing indicates defenders should assume exploit code or operational techniques are available to threat actors.

How to fix it

Apply the operating-system, firmware, or vendor security update that incorporates a fixed Arm Mali GPU kernel driver. For driver-branch remediation, move beyond the vulnerable ranges: Midgard should be updated past r31p0, while Bifrost and Valhall should be updated past r35p0, or to a vendor-confirmed fixed build. Because many devices receive the Mali driver only through OEM firmware, Android security bulletins, Linux distribution kernels, or embedded vendor BSP updates, validate the fix through the device or platform vendor rather than relying only on upstream Arm version names. Where immediate patching is not possible, reduce exposure by restricting installation and execution of untrusted local applications, disabling unnecessary shell or debug access, enforcing application allowlisting, maintaining SELinux/AppArmor or equivalent controls in enforcing mode, blocking sideloading where applicable, and prioritizing replacement or isolation of devices that cannot receive fixed firmware.

How to confirm the fix worked

Confirm that the deployed kernel, firmware, or device image contains a Mali GPU driver version outside the affected ranges or that the platform vendor explicitly identifies the build as fixed for this issue. On Linux-based systems, inventory loaded GPU modules, kernel package versions, device-tree or firmware metadata, and vendor release notes. On Android and embedded systems, verify the security patch level, OEM advisory, build fingerprint, kernel build date, and GPU driver/BSP release against vendor documentation. Attempting to reproduce exploitation is not recommended on production devices; instead, validate with authenticated inventory, kernel/module version checks, vendor patch attestations, and controlled lab testing where driver version and exploitability can be safely assessed.

Typical attack path

1. Gain local code execution on a device that uses an affected Arm Mali GPU kernel driver branch.
2. Identify that the Mali GPU driver interface is present and accessible from the current privilege context.
3. Open the GPU device interface and issue crafted driver operations or ioctls to reach the vulnerable memory-management path.
4. Manipulate memory layout so the driver grants or enables writes to pages that should remain read-only.
5. Modify kernel memory to elevate privileges, bypass sandboxing, or disable mandatory access controls.
6. Execute follow-on actions as a privileged user, such as credential theft, surveillance, persistence, lateral movement support, or tampering with security tooling.

How to detect it

There is no single universal network indicator for this vulnerability because exploitation is local and occurs inside the GPU kernel driver. To determine whether exploitation may have already occurred, collect endpoint, mobile-device, and kernel telemetry around the time of suspicious activity. Review kernel logs, Android logcat, crash dumps, pstore/ramoops records, audit logs, SELinux or AppArmor denials, EDR events, and mobile threat defense alerts for abnormal Mali driver interactions, kernel oops or panic events, unexpected privilege changes, security-control tampering, and suspicious processes accessing the GPU device interface. Look for untrusted or newly installed applications opening Mali device nodes followed by root-level actions, modification of system partitions, disabling of SELinux or verified boot signals, creation of unexpected setuid binaries, installation of persistence mechanisms, or unexplained credential and data access. Because observed exploitation may be part of a chained attack, also investigate preceding initial-access vectors such as malicious apps, browser exploitation, message-based payloads, sideloaded packages, physical debug access, or compromised local services. Absence of these artifacts does not prove non-exploitation, as successful kernel privilege escalation may leave few durable logs, especially on consumer mobile and embedded devices.

• /dev/mali0
• /dev/mali
• mali_kbase
• kbase
• mali_ioctl
• SELinux: Loaded policy from
• SELinux: Disabled at runtime
• avc: denied
• type=AVC
• kernel panic
• Oops:
• BUG: unable to handle kernel
• Unable to handle kernel paging request
• Internal error: Oops
• ramoops
• pstore
• setenforce 0
• /sys/fs/selinux/enforce
• /proc/modules
• /proc/kallsyms

What your security team should do

• Prioritize patching or firmware updates for all products using Arm Mali Midgard r26p0-r31p0, Bifrost r0p0-r35p0, or Valhall r19p0-r35p0 drivers, especially internet-connected, mobile, kiosk, embedded, or high-value user devices.
• Treat unpatched affected devices as exposed because this vulnerability is in CISA KEV and has active in-the-wild exploitation history; the KEV remediation deadline was 2023-04-20.
• Inventory devices and kernels for Arm Mali GPU usage, including Android fleets, embedded Linux devices, Chromebooks, IoT appliances, and vendor BSP-derived products.
• Where patching is delayed, restrict untrusted application execution, sideloading, debug shells, ADB access, local user accounts, and unnecessary physical or console access.
• Increase monitoring for local privilege-escalation behavior, including suspicious access to Mali GPU device nodes, unexpected root transitions, SELinux/AppArmor policy tampering, kernel crash artifacts, and post-exploitation persistence.
• For devices that no longer receive firmware updates, plan compensating controls, network isolation, reduced data exposure, or hardware replacement.