Arm Mali GPU Kernel Driver

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Critical, CVSS 9.0 - 10.0 (driver tier; the $20,000 band is the proprietary CSF firmware) │ $10,000 │ $11,000 High, CVSS 7.0 - 8.9 │ $5,000 │ $6,000 Medium, CVSS 4.0 - 6.9 │ $1,500 │ $1,875 Low, CVSS 0.1 - 3.9 │ $500 │ $625 Submit a vulnerability CVE history 4 Last 12 months 52 Lifetime Memory safety 55 % Access control 20 % Info disclosure 15 % Denial of service 5 % Latest advisories Loading the feed Overview Kbase is the GPL-2.0 Linux kernel module that drives Arm's Mali GPUs, and Mali is the most widely shipped GPU IP on earth outside Apple: the large majority of non-Qualcomm Android phones (Samsung Exynos, MediaTek Dimensity, Google Tensor, Amlogic, Rockchip, Allwinner) plus set-top boxes, TVs, automotive clusters and a huge embedded population, a blast radius on the order of a billion devices. The driver runs in kernel context and is reachable from any unprivileged app, which is exactly why it is one of the two or three most commonly exploited kernel privilege-escalation surfaces in commercial Android spyware chains; its 22 recorded CVEs understate that, because Mali fixes often ship under Arm's own advisory numbering in the Android Security Bulletin rather than an NVD-indexed CPE. Arm pays for it on a public, actively triaged Intigriti program where the driver sits in the $500 to $10,000 tier, with the $20,000 band reserved for the proprietary CSF firmware. sorona.xyz adds 1.25× on top of whatever Arm awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope Arm's program welcomes vulnerability reports in certain versions of two named assets: the Mali GPU Kernel Driver (Kbase) and the Mali Command Stream Frontend firmware (CSFFW). Kbase is the GPL-2.0 kernel module this entry covers, and it is the asset the $500 to $10,000 tier maps to The whole Kbase module as Arm publishes it, starting at the /dev/mali device node and its ioctl surface, which any application holding a GPU handle can reach GPU memory management: allocation and growable regions, mapping into user and GPU address spaces, imported user buffers and dma-bufs, and the MMU and page-table handling underneath Job and command submission on both generations, the job-manager path on older parts and the queue and group path on CSF hardware, along with fence, timeline and event delivery back to userspace Context and file-descriptor lifecycle, power and clock management, and the kernel-side interface to the CSF firmware The program's eligibility shape is part of what it accepts: the attack must be local, unprivileged and mounted from EL0 with proof-of-concept code, and it must reproduce on an unmodified driver, including the CONFIG_MALI_NO_MALI=y virtual setup Arm documents for researchers without hardware The CSF firmware itself, which the same program covers as a separate asset on a higher tier, though it is proprietary rather than part of the open-source driver Out of scope Bugs only reachable through debugfs, through privileged sysfs or procfs files an unprivileged attacker could not open, through TEST config options, or in the dummy model code The Linux kernel itself, non-Mali modules, other Mali drivers such as Lima, Panfrost and Panthor, the patches that let Kbase run on a virtual device, and a vendor's platform-specific code, which Arm asks you to take to the OEM Side-channel and covert-channel attacks, fingerprinting-style privacy reductions, and TrustZone Media Protection (TZMP) bypasses Local temporary denial of service that a reboot resolves, and theoretical issues with no realistic exploit scenario or attack surface Undefined-behaviour reports without a demonstrated exploitable impact, and out-of-date-software claims with no proof of concept. Arm invites these anyway, along with Kbase crashes and WARN traces, for a small discretionary bonus rather than a tier payment Issues Arm already knows about, closed as duplicates, and zero-days reported within 14 days of a public patch or mitigation Software and devices that no longer receive security updates, attacks needing physical access, a man in the middle or a compromised account, and spam, social engineering, DDoS or brute force Sanctioned-country residents and anyone under 18, who cannot be paid Most-valued findings Memory-safety bugs in Kbase reachable from an unprivileged app, which at 55% dominate this driver's history and are what the top band is written for: use-after-free, out-of-bounds access, and refcount errors in the ioctl and memory-management paths A full local privilege escalation chain from EL0 to kernel code execution, reproducible on an unmodified driver Access-control failures where one process reaches another's GPU memory objects, contexts, or job slots Kernel information disclosure that leaks addresses or other process memory back to userspace and makes an exploit chain practical Any of the above shown on a stock configuration, ideally with a proof of concept that also runs in Arm's documented virtualized Kbase environment Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. The attack must be local, unprivileged and mounted from userspace at EL0; anything needing root, physical access, or a compromised account does not qualify Proof-of-concept code demonstrating the impact must be included with the report The bug must reproduce on an unmodified driver and unmodified CSF firmware, though inserted delays and the config changes named in the scope are allowed Arm publishes device configuration guidelines and a virtualized test setup for Kbase, but does not help researchers acquire hardware Zero-days reported within 14 days of a public patch or mitigation are accepted but are usually not eligible for a bounty Sanctioned-country residents and under-18s are excluded from payment Disclosure Coordinated through Arm PSIRT, and strictly so: Arm requires prior written consent before you discuss or disclose vulnerability information anywhere, including proof-of-concept video on YouTube or Vimeo. File with Arm directly and let sorona.xyz track the outcome; publication timing is Arm's call, not a fixed clock. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability