Table of Contents
Code Aurora Forum (CAF) hosts tested open source software code needed to provide open source and upstream enablement for innovative, performance optimized, network connectivity and related ecosystems to support system on a chip (SoC) products. It also serves as a staging area for open source code that is submitted to various upstream projects such as theand .
The following explains several pieces that make up the final advisory and explains each individual information field as required by the advisory.
The header of the advisory should be made up by Title, Release Date, Affected Projects, Advisory ID, and CVE ID(s).
Title: A short description of the vulnerability (not the impact), as well as a listing of individual CVE ID(s) as assigned by MITRE or the respective CAF project.
Release Date: Release date of the advisory on CAF. If the advisory is a revision of an old advisory, this should reflect the publication date of the revision.
Affected Projects: A list of CAF projects that are affected by the vulnerability.
Advisory ID: Each advisory should be identifiable by a unique advisory id. This identifier is assigned by the respective CAF member s security that wishes to publish the advisory. The following scheme shall be used: PREFIX-20XX-YYYYY-REV.
Each entity publishing security advisories on CAF should use its own prefix to identify their advisory. The prefixes are maintained by CAF. Members who did not publish security advisories on CAF should coordinate with the CAF team to prevent double-usage of prefixes.
In the above identifier template, 20XX is the year;YYYYYY is a unique identifier and REV a revision number (starting at 1) that can be used in case there is a need to issue updates for regressions introduced by previous fixes for the vulnerabilities.
CVE ID(s): List of Common Vulnerability and Exposures (CVE) identifiers assigned for the specific vulnerabilities.
The main part of the advisory should contain details about the vulnerabilities that are addressed with the advisory. Each advisory should come with a high-level Description which briefly describes/lists the affected code containing the vulnerability and acknowledges security vulnerability in it.
The section should be followed by a list containing information for each individual vulnerability. Each item in this list has to contain a CVE ID, vulnerability description, access vector, security risk, and vulnerability field.
CVE ID: The list item starts with the CVE ID for this specific vulnerability. Vulnerability Description: Explain the nature of the vulnerability as well as its impact.
Access Vector: State execution environment as required by the vulnerability to get exploited. This can be either local for vulnerabilities that are exploited on-device or remote for vulnerabilities that can be triggered via external communication paths such as network protocols.
Security Risk: Quantify the security impact this vulnerability has considering its environment and use cases of the affected code and the vulnerability. Valid values for this field are low, medium, high, and critical. The meaning of those will be explained later within this document.
Vulnerability: Common Weakness Enumeration (CWE) name followed by its numerical identifier. See: http://cwe.mitre.org/data/index.html.
In addition to the vulnerability details, the advisory also shall list information of which CAF code bases are affected by the problem.
This can be free-form text listing information about which GIT branches of the projects listed in the advisory header are affected by the problem.
The previous sections are followed by a section to make general notes concerning the advisory and/or vulnerability as well as listing patches that address the vulnerability.
Note: Optional field for general remarks regarding the advisory or the patch information. This can also include mitigations for the vulnerabilities that do not require the patches to be applied.
Patch: The patch sections should link to a tar.gz file hosted on CAF that contains a patch set addressing all vulnerabilities that are listed in the advisory. This should be followed by a section that lists patches on a per-CVE ID basis.
The advisory footer ends the security advisory and gives the opportunity to publicly thank or acknowledge the finder of the security vulnerability and provide other information.
Acknowledgment: Free form text field to include acknowledgment notes and list the finder(s) of the respective issues.
Revisions: Free form text field stating whether this is a revision of a previously issued advisory and if so, it should list the advisory id of previous revisions. In this case, the original advisory id has to be used and the revision id has to be incremented by one.
Contact: Security contact of the respective CAF member that can be used by researchers and other organizations to acquire more information about the published advisory, make comments, or report further issues.
Security Risk Rating
Each vulnerability included in the advisory comes with an associated security risk rating. Ratings that should be used are low, medium, high, and critical. Following are brief descriptions of these severity levels.
Risk Rating Levels
Remote code execution, remote permanent denial of service (inoperability), bypassing or disabling critical security measures.
Critical vulnerabilities may allow an attacker to gain control of the device remotely, typically by sending a malicious input that is received and processed by the device. A vulnerability that permits an attack that may cause a device to stop functioning also falls into this category. In this case, a vulnerable device normally cannot be recovered from a hardware reset or will require an engineering procedure for recovery. Vulnerabilities that allow bypassing or disabling of a critical security mechanism, either locally or remotely, are also covered by this category. Examples include full compromises of a secure execution environment and secure boot bypasses.
Local privilege escalation, access to confidential device information or other confidential user information maintained on device, temporary remote denial-of-service attacks.
High vulnerabilities may allow an unprivileged attacker to escalate privileges from a local execution context, and to execute arbitrary code and allow access to confidential device information including device secrets, security settings, and user confidential data via local access. This category also includes vulnerabilities that may allow an attacker to remotely (without any user assistance) cause the device to crash and/or reboot, i.e., temporary denial-of-service attacks. Examples of confidential device information may include the device A-key or SIM-lock information and contents of secure storage, including DRM keys and GPS information.
Medium vulnerabilities may allow an attacker to achieve similar impact to high-rated ones, but require additional user interaction or another vulnerability to work together, e.g., local privilege escalation attacks that require an elevated privilege above normal user privileges as a prerequisite. Additionally, this category includes vulnerabilities that may allow an attacker to access sensitive, but not security-critical device configuration information from the host without authorization, e.g., exact device or firmware versions, IMEI, or phone number (which could be further used by an attacker to identify vulnerabilities specific to the device). Accordingly, these vulnerabilities potentially enable an attacker to mount more dangerous attacks.
Low vulnerabilities are security vulnerabilities that do not directly cause harm to the user or the device. They include access to general information such as general device settings or device-specific details such as device manufacturer, model, or HLOS in use. Vulnerabilities that do not qualify for any of the above categories, but that may add to the overall impact of another vulnerability, also fall into this category. This category also includes Defense-in-Depth issues that do not have an attack vector at the time of issue discovery, but improved code can mitigate the attack if other defense measures are rendered ineffective.
The rating of individual cases may differ from the above guideline if other information becomes available such as the existence of an exploit in the wild exploiting the vulnerability. The exact risk rating to be used for the advisory should be determined in coordination with the security team of the respective CAF member.