11. DPDK Vulnerability Management Process

11.1. Scope

This security process covers only the main repositories (dpdk and dpdk-stable) of the core project (including experimental APIs). The team will not apply fixes to stable branches declared unmaintained (end of life).

All vulnerabilities are bugs, but not every bug is a vulnerability. Vulnerabilities compromise one or more of:

  • Confidentiality (personal or corporate confidential data).

  • Integrity (trustworthiness and correctness).

  • Availability (uptime and service).

If in doubt, consider the vulnerability as security sensitive. At worst, the response will be to report the bug through the usual channels.

11.2. Finding

There is no pro-active security engineering effort at the moment.

Report any security issue you find in DPDK as described below.

11.3. Reporting

Do not use Bugzilla to report security vulnerabilities, as it is not secured for such communication. Instead, send a GPG-encrypted email to security@dpdk.org. This address is open to all, but access to its inbox is intentionally limited to a small group to minimize the risk of early disclosure.

GPG-sign any one-on-one correspondence related to the vulnerability report as part of maintaining a secure communication process.

As with any bug report, detailed information greatly aids in diagnosing and resolving the issue. If you have already developed a fix, include it in your submission to help accelerate resolution.

In your report, specify how you would like to be credited for the discovery and mention any embargo period you wish to impose.

If the vulnerability has not yet been made public, do not disclose patches or related information publicly. Even if a fix has already been published, you must still follow the proper reporting process outlined here.

11.4. Confirmation

Upon receiving the report, a security team member should reply to the reporter acknowledging receipt.

The DPDK security team reviews the security vulnerability reported. Area experts who are not members of the security team may be involved in the process. If the reported issue does not qualify as a security vulnerability, the security team will request the submitter to report it using the usual channel (Bugzilla). If qualified, the security team assesses which DPDK versions are affected. A bugzilla ID (allocated from a reserved pool) is assigned to the vulnerability, and kept empty until public disclosure.

The security team calculates the severity score with the CVSS calculator based on inputs from the reporter and its own assessment of the vulnerability, and agrees on the score with the reporter.

An embargo may be put in place depending on the severity of the vulnerability. If an embargo is decided, the security team should suggest the duration and negotiate with the reporter. Embargo duration between vulnerability confirmation and public disclosure should be between one and ten weeks. If an embargo is not required, the vulnerability may be fixed using the standard patch process, once a CVE number has been assigned.

Send the confirmation mail within 3 business days.

Include the following information in the mail:

  • Confirmation

  • CVSS severity and score

  • Embargo duration

  • Reporter credit

  • Bug ID (empty and restricted for future reference)

11.5. CVE Request

The security team develops a security advisory document. The security team may, at its discretion, include the reporter (via “CC”) in developing the security advisory document, but in any case should accept feedback from the reporter before finalizing the document. When the document is final, the security team needs to request a CVE identifier from a CNA.

Send the CVE request to secalert@redhat.com using GPG encrypted email (see contact details).

11.5.1. CVE Request Template with Embargo

A vulnerability was discovered in the DPDK project.
In order to ensure full traceability, we need a CVE number assigned
that we can attach to private and public notifications.
Please treat the following information as confidential during the embargo
until further public disclosure.

[PRODUCT]:
[VERSION]:
[PROBLEMTYPE]:
[SEVERITY]:
[REFERENCES]: { bug_url }
[DESCRIPTION]:

Thanks
{ DPDK_security_team_member }, on behalf of the DPDK security team

11.5.2. CVE Request Template without Embargo

A vulnerability was discovered in the DPDK project.
In order to ensure full traceability, we need a CVE number assigned
that we can attach to private and public notifications.

[PRODUCT]:
[VERSION]:
[PROBLEMTYPE]:
[SEVERITY]:
[REFERENCES]: { bug_url }
[DESCRIPTION]:

Thanks
{ DPDK_security_team_member }, on behalf of the DPDK security team

11.6. Fix Development and Review

If the fix is already published, skip this step, and replace the pre-release disclosure with the private disclosure, as described below. This should not be considered the standard process.

This step may start in parallel with CVE creation. The security team and elected area experts who agree to maintain confidentiality develop and review patches fixing the vulnerability.

Reference the CVE id and the bug id in the patch if there is no embargo, or if the embargo will be lifted when the release including the patch is published. If the embargo will be lifted after the release, omit the CVE and bug ids from the commit message.

Backports to the identified affected versions are done once the fix is ready.

11.7. Pre-Release Disclosure

When the fix is ready, send the security advisory and patches to downstream stakeholders (security-prerelease@dpdk.org), specifying the date and time of the end of the embargo. The communicated public disclosure date should be less than one week.

Downstream stakeholders are expected not to deploy or disclose patches until the embargo passes; otherwise they will be removed from the list.

Downstream stakeholders (in security-prerelease list) are:

  • Operating system vendors known to package DPDK

  • Major DPDK users, considered trustworthy by the technical board, who have made the request to techboard@dpdk.org

The OSS security private mailing list will also be contacted one week before the end of the embargo, as indicated by the OSS-security process and using the PGP key listed on the same page, describing the details of the vulnerability and sharing the patch[es]. Distributions and major vendors follow this private mailing list, and it functions as a single point of contact for embargoed advance notices for open source projects.

The security advisory will be based on the template below, and will be sent signed with a security team member’s GPG key.

11.7.1. Pre-Release Mail Template

This is an advance warning of a vulnerability discovered in DPDK,
to give you, as downstream stakeholders, a chance to coordinate
the release of fixes and reduce the vulnerability window.
Please treat the following information as confidential until
the proposed public disclosure date.

{ impact_description }

Proposed patches are attached.
Unless a flaw is discovered in them, these patches will be merged
to { branches } on the public disclosure date.

CVE: { cve_id }
Severity: { severity }
CVSS scores: { cvss_scores }

Proposed public disclosure date/time: { disclosure_date } at 15:00 UTC.
Please do not make the issue public (or release public patches)
before this coordinated embargo date.

If the issue is leaked during the embargo, follow the same procedure with only a few days delay between the pre-release and the public disclosure.

11.8. Private Disclosure

If a vulnerability is unintentionally already fixed in the public repository, send a security advisory to downstream stakeholders (security-prerelease@dpdk.org), giving a few days to prepare for updating before the public disclosure.

11.8.1. Private Disclosure Mail Template

This is a warning of a vulnerability discovered in DPDK,
to give you, as downstream stakeholders, a chance to coordinate
the deployment of fixes before a CVE is public.

Please treat the following information as confidential until
the proposed public disclosure date.

{ impact_description }

Commits: { commit_ids with branch number }

CVE: { cve_id }
Severity: { severity }
CVSS scores: { cvss_scores }

Proposed public disclosure date/time: { disclosure_date }.
Please do not make the vulnerability information public
before this coordinated embargo date.

11.9. Public Disclosure

When the embargo expires, carry out the following actions simultaneously:

  • A security team member files the assigned bug with all relevant details and makes it publicly accessible.

  • Push the associated patches to the appropriate branches.

  • Release updated versions for all affected stable branches, both short-term and long-term.

To ease adoption by system administrators, preferably schedule security releases between Monday and Wednesday, avoiding weekends.

Post the security advisory to announce@dpdk.org and to the public OSS-security mailing list as soon as the patches are pushed to the appropriate branches.

Send patches to dev@dpdk.org and stable@dpdk.org accordingly.

11.9.1. Release Mail Template

A vulnerability was fixed in DPDK.
Some downstream stakeholders were warned in advance
in order to coordinate the release of fixes
and reduce the vulnerability window.

{ impact_description }

Commits: { commit_ids with branch number }

CVE: { cve_id }
Bugzilla: { bug_url }
Severity: { severity }
CVSS scores: { cvss_scores }

11.10. References