Arm

Description

Arm is committed to security and welcomes feedback from researchers and the security community to improve its products and services.

The Arm Bug Bounty Program represents a partnership between Arm and the research community. At Arm, we value collaboration with security researchers as a critical step toward enhancing the security of our products. We encourage researchers to work with us to identify, mitigate, and responsibly disclose potential security vulnerabilities. We look forward to collaborating with you!

This program currently welcomes reports of vulnerabilities in certain versions of:

• Firmware: Mali Command Stream Frontend (CSF) Firmware 'CSFFW'
• Software: Mali GPU Kernel Driver (Kbase)

By submitting your report, you agree to the terms of the Arm Bug Bounty Program. Arm reserves the right to alter the terms and conditions of this program at any time and its sole discretion.

Rules of engagement

To be eligible for the Arm Bug Bounty Program, you must not:

• Be a resident of, or make your submission from, a country against which the US, UK or EU has embargoed, sanctioned, or otherwise controlled/restricted (e.g., Cuba, Iran, North Korea, Sudan, Syria, Russia, etc.).
• Be, be affiliated with or work for, an entity which the US, UK or EU has embargoed, sanctioned, or otherwise controlled/restricted.
• Be legally prohibited from being rewarded by Arm or Intigriti for any reason.
• Be a current employee of Arm, its affiliates or subsidiaries, or an employee who has left Arm, its affiliates or subsidiaries within the past 12 months.
• Be an immediate family member of a current employee of Arm, its affiliates or subsidiaries, or an immediate family member of an employee who has left Arm, its affiliates or subsidiaries within the past 12 months.
• Be less than 18 years of age.

By participating in this program, you agree to:

• Respect the Community Code of Conduct
• Respect the Intigriti Terms and Conditions
• Respect the scope of the program
• Not discuss or disclose vulnerability information without prior written consent from Arm PSIRT (including PoC's on YouTube and Vimeo)
• Your relationship with Arm in the context of your participation in any Arm Program (as defined in the Researcher T&C) is exclusively governed by the law of England & Wales, and the courts of London, England, will have sole jurisdiction for any claims or disputes between you and Arm in the context thereof.

Safe harbor for researchers is applied

Arm considers ethical hacking activities conducted consistent with the Researcher Guidelines, the Program description and restrictions (the Terms) to constitute “authorized” conduct under criminal law. Arm will not pursue civil action or initiate a complaint for accidental, good faith violations, nor will they file a complaint for circumventing technological measures used by us to protect the scope as part of your ethical hacking activities.

Please note that Arm is not able to grant authority or safe harbor to researchers for any security vulnerability testing of third-party software or systems.

In scope

General Eligibility

• Attack must be local, unprivileged and in userspace (EL0).
• A proof-of-concept ('PoC') code must be included to demonstrate the vulnerability's impact.
• The vulnerability must be reproducible with an unmodified driver and unmodified CSFFW
  • Delays that have been inserted into codepaths are allowable.
  • Config changes that are listed in the scope are allowable.

Eligible Device Configurations

Arm has provided guidance on configuring a suitable test environment. Please see the attached arm_gpu_bug_bounty_device_configuration_guidelines.pdf for details. Note that Arm is unable to assist with acquiring devices for testing.

It is possible to conduct some testing of the 'Kbase' GPU Kernel Driver using a virtualized environment. Guidance for configuring a virtual environment has been provided in the FAQ section below.

Note: As noted in the FAQ, early Valhall GPUs are Job Manager (JM) GPUs while later Valhall GPUs are Command Stream Frontend (CSF) GPUs. The packages for Valhall vary in their support of JM & CSF depending on the version number; since it is not clear from the version & documentation which packages support JM GPUs & which support CSF GPUs, we advise using https://developer.arm.com/downloads/-/Mali%205th%20Gen%20GPU%20Architecture for testing CSF GPUs, ensuring you target the latest GPU when compiling (e.g. if using CONFIG_MALI_NO_MALI=y)

A note on AI-assisted submissions

LLMs have been revolutionary for vulnerability discovery, and we welcome the use of AI tools. However, we are receiving many submissions that simply copy LLM-generated findings without validating their accuracy, reproducibility or security impact.

Arm has invested significantly in AI, including developing Arm Metis, an agentic AI security framework to help find vulnerabilities. Bug bounty reports that simply reproduce tool output are therefore likely to just reproduce information we already have. Submissions must go beyond identifying a potential bug and demonstrate that the bug can be exploited to cause a meaningful security impact, through a clear reproducible PoC that we can easily run in our internal test environments.

Reports without sufficient evidence will be closed but may be resubmitted once fully validated. We acknowledge that this may result in valid findings being rejected, but this helps us assess findings consistently and only reward clear, reproducible and actionable research.

Feedback

Would you like to help us improve our program or have some feedback to share, please send your anonymous feedback here:

Program feedback link Please note this form will be checked periodically and should not be used for submission or support queries.

Out of scope

General Exclusions for the Arm Bug Bounty program

• A report of undefined behavior violation on its own, without proof that it causes an exploitable vulnerability
• Local Temporary Denial of Service attacks that are resolved by rebooting the device
• Vulnerabilities that lower privacy for the user, for example by allowing their device or profile to be fingerprinted
• Covert Channels
• Side channel attacks
• A bypass of TrustZone® Media Protection (TZMP)
• Vulnerabilities already known to Arm, these will be flagged as a duplicate
• Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited
• Spam, social engineering and physical intrusion
• DDoS attacks or brute force attacks
• Vulnerabilities that only work on software or devices that no longer receive security updates
• Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
• Recently discovered zero-day vulnerabilities found in in-scope assets within 14 days after the public release of a patch or mitigation may be reported, but are usually not eligible for a bounty
• Reports that state that software is out of date/vulnerable without a proof-of-concept

Additional Exclusions

Mali GPU Kernel Driver

• Vulnerabilities that are only exposed through the use of debugfs, even if those files are world-readable/world-writable.
• Vulnerabilities that are only exposed through the use of privileged sysfs or procfs files.
  • That is, those files that an unprivileged attacker would not have access to.
• Vulnerabilities that require page migration to be enabled. This applies regardless of whether kbase_page_migration_enabled is explictly enabled, or whether the device GPUs enable this by default (such as Mali-G925 and Mali-G1)
• Vulnerabillities that are only exposed through the use of TEST config options.
• Vulnerabillities in the "dummy model" code.
• Vulnerabilities in non-mali modules, or Mali Kernel drivers other than 'Kbase' (such as Lima, Panfrost, Panthor).
• Vulnerabilities in the Linux kernel.
• Vulnerabilities in the patches provided to allow Kbase to be used on a Virtual Device.
• Vulnerabilities in parts of the code not intended for use on production systems, e.g., exposure of performance counters or instrumentation to untrusted users where it is reasonable to expect a production system to protect access via other means (see https://blog.google/security/further-hardening-android-gpus/) or other features intended for use by developers
• Vulnerabilities using kbase code for an execution model not supported by the selected DDK release. This applies when CSF code is compiled from a JM-only release, or JM code is compiled from a CSF-only release, including with CONFIG_MALI_NO_MALI=y. Please see the FAQ for more information on JM & CSF.
• Vulnerabilities in a vendor(s)' platform specific code. Arm strongly recommends to report such vulnerabilities to the relevant device providers/OEMs.

Reporting Out of Scope Issues

If in the course of your research you identify valid functional bugs or security issues which do not meet the criteria for bounty payment, please submit these as we may consider them for a small discretionary bonus. Examples include:

• Kernel Warnings produced by Kbase via WARN* macros, which produce a Call trace
• Any crash of the Kbase driver, such as those:
  • causing the caller process to be killed
  • causing the caller process to be unkillable
  • requiring the device to be rebooted
• Undefined behavior violations

For example, a NULL pointer dereference in the Kbase driver may cause a crash, but might not result in an In Scope vulnerability.

Severity

The decision to grant a reward (bounty or bonus) for a vulnerability report, and the value of that reward (if any), is entirely within Arm’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the demonstrated impact and severity of the reported vulnerability.

Some examples of vulnerabilities we are interested in hearing about are:

High Severity

• Vulnerabilities that could be used to gain root privileges
• Vulnerabilities that allow the execution of unauthorized code (e.g. via ROP) on the GPU's Firmware.

We do not require you to demonstrate being able to get root privileges, only that the area modified is sensitive enough that it could happen.

Medium Severity

• Vulnerabilities that could be used to gain control over other userspace processes
• Vulnerabilities that expose sensitive data normally inaccessible to the attacker's EL0 process that presents a direct serious impact.

We do not require you to demonstrate being able to gain control over another userspace process, only that the area modified is sensitive enough that it could happen.

Low Severity

• Vulnerabilities that expose sensitive data or metadata that is normally inaccessible to the attacker's EL0 process.

FAQ

Please refer to the following attached documents:

• Arm GPU Bug Bounty FAQ: arm_gpu_bug_bounty_faq.pdf
• Arm GPU Bug Bounty How-To Guide: arm_gpu_bug_bounty_how_to_guide.pdf
• Arm GPU Bug Bounty Virtual Platform How-To Guide: arm_gpu_virtual_platform_how_to_guide.pdf