CVE-2024-4610

What it actually does

CVE-2024-4610 is a use-after-free flaw in Arm Mali Bifrost and Valhall GPU kernel drivers, affecting driver releases r34p0 through r40p0. A local, non-privileged user or application can trigger improper GPU memory handling so the kernel driver accesses memory after it has been freed. Because the vulnerable component runs in kernel context, successful exploitation can allow local privilege escalation with high confidentiality, integrity, and availability impact, including arbitrary kernel memory access, kernel code execution, sandbox escape, or device compromise.

Why it matters to the business

This vulnerability can turn code execution inside a low-privileged local app or process into control over the affected device. On mobile, embedded, and Linux-based systems using affected Mali GPU drivers, that can lead to spyware deployment, data theft, device surveillance, persistence, or disruption. It is listed in CISA KEV with active exploitation in the wild and a remediation due date of 2024-07-03, so organizations operating affected devices should treat it as urgent even though EPSS is relatively low, because exploitation has already been observed and has been associated with commercial spyware activity, including Intellexa/Predator-related reporting.

How an attack unfolds

An attacker first needs local code execution on a device using an affected Arm Mali Bifrost or Valhall GPU kernel driver, typically through a malicious application, chained browser exploit, document exploit, or another foothold that can run code as an unprivileged user. The attacker then interacts with the GPU device interface exposed by the Mali driver, such as the kernel GPU character device, and issues crafted memory-management or GPU job operations that create a race or stale reference inside the driver. The driver later reuses or dereferences memory that has already been freed. By shaping heap state and reclaiming the freed memory with attacker-controlled data, the attacker can corrupt kernel memory or redirect kernel execution. Successful exploitation can elevate the attacker from an app or unprivileged process to kernel-level control, allowing disabling of protections, access to data from other apps or processes, installation of spyware, or persistence. Public reporting and KEV status indicate this class of vulnerability has been used in real-world attacks, including spyware-style exploitation chains rather than broad unauthenticated internet scanning.

How to fix it

Upgrade affected Arm Mali GPU kernel drivers from vulnerable releases r34p0 through r40p0 to a vendor-provided fixed release. Where available, deploy the device, OS, BSP, kernel, or firmware update from the OEM or platform vendor that incorporates the corrected Arm Mali driver. If an exact package-level fixed version is not available from the product supplier, request confirmation that the shipped driver is newer than the affected r34p0-r40p0 range or contains the backported fix for CVE-2024-4610. For managed mobile and embedded fleets, prioritize security patch levels or firmware images released after the vendor incorporated the Arm fix. If immediate patching is not possible, reduce exposure by limiting installation of untrusted applications, enforcing application allowlisting, restricting local shell/debug access, disabling unnecessary GPU access in containerized or kiosk workloads where feasible, and increasing monitoring for local privilege escalation behavior. Because this is a KEV-listed vulnerability with observed exploitation, mitigation should not be considered a long-term substitute for applying the vendor fix.

How to confirm the fix worked

Confirm the device or image no longer includes Arm Mali Bifrost or Valhall GPU kernel driver releases r34p0 through r40p0 unless the vendor has explicitly backported the fix. Validate through vendor security bulletins, OS or firmware build notes, kernel module metadata, package manifests, BSP release notes, or driver version strings exposed by the platform. On Linux-derived systems, inspect loaded modules, kernel logs, firmware manifests, and GPU driver package versions for Mali/kbase driver version information. On Android-derived systems, confirm the applicable Android security patch level or OEM bulletin includes the Mali GPU driver fix and test that devices are running the remediated build. Where feasible, run vendor-approved vulnerability validation or compliance checks rather than public exploit code. Also confirm that untrusted users or applications do not have unnecessary access to GPU device nodes and that endpoint telemetry continues to collect kernel crash, SELinux, audit, and application execution events.

Typical attack path

1. Identify a target device using an affected Arm Mali Bifrost or Valhall GPU kernel driver release r34p0 through r40p0.
2. Gain local code execution as a low-privileged user or app, often through a malicious app, drive-by exploit chain, or another initial-access vulnerability.
3. Open or interact with the Mali GPU kernel device interface exposed to user space.
4. Trigger crafted GPU memory processing operations that cause the driver to reference freed memory.
5. Manipulate kernel heap layout so the freed allocation is replaced with attacker-controlled data.
6. Use the resulting memory corruption to read or write kernel memory or achieve kernel code execution.
7. Escalate privileges, bypass sandbox or SELinux-style controls, and access protected data or install surveillance tooling.
8. Clean up artifacts where possible, leaving limited evidence beyond driver crashes, anomalous GPU device access, or endpoint telemetry.

How to detect it

Retrospective detection is difficult because exploitation occurs locally in a kernel GPU driver and may not create a distinctive network signature. Focus on endpoint and device telemetry around the time of suspicious app execution, crashes, or privilege changes. Review kernel logs, crash dumps, pstore/ramoops records, audit logs, SELinux denials, MDM/EDR telemetry, and application installation history for untrusted processes interacting with Mali GPU device nodes followed by kernel faults, privilege escalation, security control tampering, or spyware-like behavior. On Linux systems, examine auditd or eBPF telemetry for opens or ioctls to /dev/mali0 or related Mali render devices by unexpected users, containers, or applications. On Android-derived systems, review logcat, tombstones, kernel panic logs, SELinux AVC denials, app install events, package provenance, and mobile threat defense alerts for suspicious apps followed by kbase/mali driver errors or privilege changes. Because Intellexa/Predator-style activity has been linked in public reporting, also hunt for post-exploitation indicators such as unusual persistence, unexpected privileged processes, anomalous outbound connections from mobile devices, tampering with security services, and data collection activity. Kernel messages containing Mali/kbase memory errors, use-after-free symptoms, GPU job faults, or repeated device resets should be treated as suspicious when correlated with untrusted local code execution, but they are not by themselves proof of exploitation.

• /dev/mali0
• /dev/mali
• mali_kbase
• kbase
• kbase_jd
• kbase_mem
• mali_csffw
• mali:
• Mali GPU
• GPU fault
• job fault
• kbasep_js
• kbase_jd_done
• kbase_mem_free
• kbase_mem_alloc
• Unable to handle kernel NULL pointer dereference
• BUG: KASAN: use-after-free
• use-after-free in mali
• use-after-free in kbase
• SELinux avc: denied
• ioctl /dev/mali0
• open /dev/mali0

What your security team should do

• Treat this as high priority because it is CISA KEV-listed, actively exploited in the wild, and associated with spyware-style campaigns despite a low EPSS score.
• Inventory devices, firmware images, kernels, and BSPs that use Arm Mali Bifrost or Valhall GPU drivers, especially releases r34p0 through r40p0.
• Obtain and deploy OEM, OS, kernel, or firmware updates that incorporate the fixed Mali GPU driver; verify remediation before closing the finding.
• Prioritize mobile, executive, high-risk user, embedded, kiosk, and internet-exposed management device populations where local exploitation could lead to sensitive data exposure.
• Restrict installation of untrusted applications and enforce application allowlisting or mobile threat defense controls until patching is complete.
• Hunt for signs of local privilege escalation, suspicious GPU device access, kernel crashes involving Mali/kbase components, and spyware-related post-exploitation behavior.
• Review EDR, MDM, auditd, SELinux, kernel, and crash logs for activity by untrusted apps or processes accessing Mali GPU device nodes.
• If compromise is suspected, preserve full device images or forensic backups before wiping, because kernel-level spyware may remove or hide artifacts.
• Use the CISA KEV due date of 2024-07-03 as the minimum remediation benchmark for regulated or federal-aligned programs.