CVE-2021-28663

What it actually does

This is a use-after-free condition in the Arm Mali GPU kernel driver caused by incorrect handling of GPU memory operations. A process that can reach the Mali GPU driver interface may be able to cause the driver to operate on freed kernel/GPU memory, leading to kernel memory disclosure, corruption of kernel memory, privilege escalation, or denial of service. The affected driver lines include Bifrost r0p0 through r28p0 before r29p0, Valhall r19p0 through r28p0 before r29p0, and Midgard r4p0 through r30p0. Because the vulnerable code runs in kernel context, successful exploitation can give an attacker control beyond the original application sandbox or user account.

Why it matters to the business

Compromise of a vulnerable device can allow an attacker who already has a foothold, such as a malicious app or low-privileged process, to gain elevated control over the system, access sensitive data, disable security controls, persist, or disrupt device availability. This vulnerability is listed in CISA KEV and has been exploited in the wild, with the KEV remediation deadline having passed on 2021-11-17, so unpatched systems should be treated as high-priority exposure even though the EPSS value is moderate and stable over the last 30 days. Organizations using affected Arm Mali-based systems, embedded devices, Android builds, Linux platforms, or downstream software carrying the vulnerable driver should prioritize vendor firmware, kernel, and driver updates.

How an attack unfolds

An attacker first obtains the ability to execute code with low privileges on a device that exposes a vulnerable Arm Mali GPU driver, commonly through a malicious application, browser/app exploit chain, compromised user process, or another initial access method. The attacker then interacts with the Mali GPU device interface and triggers a sequence of GPU memory allocation, mapping, unmapping, or job submission operations that causes the driver to free an object while it can still be referenced. By reclaiming or influencing the freed memory, the attacker attempts to leak kernel memory or overwrite security-relevant kernel structures. Successful exploitation can escalate privileges from an untrusted or sandboxed process to kernel-level capabilities, allowing additional payloads, credential or token theft, disabling of protections, persistence, or further lateral activity. Active exploitation has been observed in the wild, so detections should focus on suspicious local privilege escalation behavior around Mali GPU device access rather than only remote network indicators.

How to fix it

Upgrade the Arm Mali GPU kernel driver or vendor firmware/kernel package to a fixed release. For Arm upstream driver lines, use Bifrost r29p0 or later, Valhall r29p0 or later, and an OEM/vendor-provided fixed build for affected Midgard r4p0 through r30p0 platforms. Because many devices receive Mali driver fixes through OEM firmware, Android security updates, Linux distribution kernels, BSPs, or embedded vendor images, apply the latest security update from the device, OS, or SoC vendor rather than attempting to patch the GPU driver in isolation. Where the listed downstream package is relevant, update kovidgoyal/kitty from Git to a version containing commit 82c137878c2b99100a3cdc1c0f0efea069313901; however, validate whether that package mapping is applicable because the described vulnerability is in the Arm Mali GPU kernel driver. If immediate patching is not possible, reduce exposure by restricting untrusted code execution, limiting access to GPU device nodes to only required users/groups, enforcing application sandboxing and SELinux/AppArmor policies, disabling unnecessary GPU acceleration for untrusted workloads where feasible, and monitoring for suspicious GPU-driver access followed by privilege changes.

How to confirm the fix worked

Confirm the running kernel, firmware, Android security patch level, or vendor BSP includes the Arm Mali driver fix for the affected branch. On Linux-based systems, inventory Mali-related kernel modules and driver versions using package manager metadata, vendor release notes, modinfo where available, dmesg output, and filesystem inspection for Mali driver modules. Verify that Bifrost and Valhall deployments are at r29p0 or later, and that Midgard deployments have a vendor-advised fixed driver or firmware build. Confirm device-node permissions for /dev/mali*, /dev/dri/*, and related GPU interfaces are limited to expected users and services. For downstream source deployments that cite kovidgoyal/kitty, verify the installed Git revision contains commit 82c137878c2b99100a3cdc1c0f0efea069313901 if that package is in scope. After patching, run authenticated vulnerability scans, mobile/embedded fleet compliance checks, or kernel package audits to ensure no vulnerable driver builds remain.

Typical attack path

1. Gain execution as a low-privileged user, app, or sandboxed process on a system using an affected Arm Mali GPU kernel driver.
2. Confirm access to the Mali GPU driver device interface, such as /dev/mali0 or related kernel GPU interfaces.
3. Trigger vulnerable GPU memory-management operations to create a use-after-free condition in the kernel driver.
4. Manipulate memory reuse to disclose kernel data or corrupt kernel memory.
5. Escalate privileges or escape an application sandbox by modifying process credentials, kernel state, or security-control state.
6. Deploy follow-on tooling, persistence, data collection, or additional payloads with elevated privileges.

How to detect it

There are no universal network indicators for this vulnerability because exploitation is typically local and occurs through the GPU kernel driver interface. Hunt using endpoint, kernel, audit, EDR, mobile, and firmware telemetry. Relevant log sources include dmesg/kern.log/messages, Android logcat and tombstones, auditd syscall records, SELinux/AppArmor denial logs, EDR process trees, package installation history, kernel module inventories, and device-node access telemetry. Look for untrusted or unexpected processes opening /dev/mali0, /dev/mali, /dev/dri/renderD*, or related GPU interfaces followed by kernel warnings, GPU page faults, process crashes, privilege changes, spawning of root shells, disabling of SELinux/AppArmor, suspicious setuid file creation, kernel module loading, or persistence installation. Investigate Mali driver crashes or kernel oops messages involving kbase, mali_kbase, GPU memory, job submission, page faults, or use-after-free conditions. On Android and embedded platforms, correlate newly installed or sideloaded applications with Mali driver faults, system_server instability, unexpected root access, remounting of system partitions, or changes to boot/vendor partitions. Because active exploitation has been observed in the wild and exploitation may leave limited artifacts after reboot, absence of logs is not proof of non-exploitation; prioritize patch verification and forensic review on high-risk devices.

• /dev/mali0
• /dev/mali
• /dev/dri/renderD
• mali_kbase
• kbase
• mali_kbase:
• Mali GPU
• GPU page fault
• gpu fault
• job fault
• kernel Oops
• BUG: KASAN: use-after-free
• use-after-free
• Unable to handle kernel paging request
• Oops:
• general protection fault
• segfault at
• avc: denied
• setenforce 0
• insmod
• modprobe
• /system/bin/su
• /system/xbin/su
• /data/local/tmp/
• /vendor/lib/modules/mali_kbase.ko
• mali.ko
• 82c137878c2b99100a3cdc1c0f0efea069313901

What your security team should do

• Treat vulnerable systems as urgent because this vulnerability is in CISA KEV, is known to be exploited in the wild, and the federal remediation due date of 2021-11-17 has long passed.
• Prioritize patching internet-connected, user-facing, mobile, kiosk, VDI, embedded, and shared systems where untrusted code or apps can execute and reach the GPU driver.
• Inventory Arm Mali GPU usage across Android devices, Linux endpoints, embedded products, appliances, and vendor-supplied images; do not rely only on application package inventories.
• Apply vendor firmware, kernel, BSP, or Android security updates that include the Mali driver fix, and verify driver branch/version after deployment.
• Restrict access to Mali GPU device nodes and related render nodes to only users and services that require GPU acceleration.
• Hunt for signs of local privilege escalation after suspicious access to /dev/mali*, /dev/dri/renderD*, or Mali kernel logs, especially on systems that were exposed before patching.
• Review EDR, auditd, SELinux/AppArmor, kernel, and mobile telemetry for low-privileged processes spawning privileged shells, modifying security settings, or loading persistence shortly after GPU-driver interaction.
• If exploitation is suspected, preserve volatile evidence, collect kernel logs and process telemetry, and consider full device reimaging or firmware reflashing because kernel-level compromise can undermine endpoint trust.