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.

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.

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.

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.
• 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 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.

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.

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