Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Jun 04, 2026 at 05:50:48PM +0100, Daniel P. Berrangé wrote:
> It is no longer viable to handle the incredible volumes of
> AI assisted security disclosures via email, nor are extended
> embargos practical or useful.
> 
> Remove all information about the current security process and
> instruct reporters to use 'confidential' issues. In contrast
> to the old highly restrictive "need to know" approach, the
> new approach makes all security issues visible to all QEMU
> maintainers immediately.
> 
> The focus is on making issues public as soon as possible with
> a viable patch. Co-ordinated disclosure will no longer be
> attempted and nor will requests to embargoes be accepted.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  contribute/report-a-bug.md     |   9 +-
>  contribute/security-process.md | 280 ++++++++++++++-------------------
>  2 files changed, 119 insertions(+), 170 deletions(-)
> 
> diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> index fd3bc6b..b506f9f 100644
> --- a/contribute/report-a-bug.md
> +++ b/contribute/report-a-bug.md
> @@ -11,6 +11,11 @@ on GitLab, taking into account the following guidance.
>    requested pieces of information that are relevant to the
>    discovered bug.
>  
> +* Bugs which are suspected, or known, to have security implications
> +  **must** be marked as "*confidential*" prior to submitting the
> +  disclosure. Consult the [security process](../security-process)
> +  for further guidance on security issue handling.
> +

Do we want to do like linux does, and make AI found issues public,
on the assumption that bad guys can find them just as easily?



>  * Reproduce the problem with the latest upstream QEMU release.
>    Reports against older versions may not be acted upon with
>    with the same priority.
> @@ -37,10 +42,6 @@ on GitLab, taking into account the following guidance.
>    guidelines](../submit-a-patch/). QEMU does not use a merge
>    request workflow for contribution.
>  
> -* Do NOT report security issues (or other bugs, too) as "confidential"
> -  bugs in the bug tracker.  QEMU has a [security process](../security-process)
> -  for issues that should be reported in a non-public way instead.
> -
>  * If the problem is believed to lie in the KVM kernel module,
>    following the [KVM wiki bug report](https://www.linux-kvm.org/page/Bugs)
>    guidance to submit an issue to the kernel bug tracker.
> diff --git a/contribute/security-process.md b/contribute/security-process.md
> index 5c708f5..a500b16 100644
> --- a/contribute/security-process.md
> +++ b/contribute/security-process.md
> @@ -3,169 +3,117 @@ title: Security Process
>  permalink: /contribute/security-process/
>  ---
>  
> -Please report any suspected security issue in QEMU to the security mailing
> -list at:
> -
> -* [\<qemu-security@nongnu.org\>](https://lists.nongnu.org/mailman/listinfo/qemu-security)
> -
> -Note that not all areas of QEMU are considered to provide a security
> -boundary. Consult the guidance at the end of this page for further
> -information on how QEMU classifies issues as security vulnerabilities
> -vs regular bugs.
> -
> -## How to report an issue:
> -
> -* Please include as many details as possible in the issue report.
> -  Ex:
> -    - QEMU version, upstream commit/tag
> -    - Host & Guest architecture x86/Arm/PPC, 32/64 bit etc.
> -    - Affected code area/snippets
> -    - Stack traces, crash details
> -    - Malicious inputs/reproducer steps etc.
> -    - Any configurations/settings required to trigger the issue.
> -
> -* Please share the QEMU command line used to invoke a guest VM.
> -
> -* Please specify whom to acknowledge for reporting this issue.
> -
> -* If any automated tools (AI/LLM based, traditional static
> -  analysis, or fuzzers) were used to discover the issue, the
> -  reporter is required to declare this at the start of the
> -  security report. Users of such tools are required to perform
> -  triage of their output. Findings and reproducer scenarios
> -  output by automated tools must be validated prior to submitting
> -  an issue to the QEMU security team.
> -
> -## How we respond:
> -
> -* Process of handling security issues comprises following steps:
> -
> -  0) **Acknowledge:**
> -    - A non-automated response email is sent to the reporter(s) to acknowledge
> -      the reception of the report. (*60 day's counter starts here*)
> -
> -  1) **Triage:**
> -    - Examine the issue details and confirm whether the issue is genuine
> -    - Validate if it can be misused for malicious purposes
> -    - Determine its worst case impact and severity
> -      [Low/Moderate/Important/Critical]
> -
> -  2) **Response:**
> -    - Negotiate embargo timeline (if required, depending on severity)
> -    - Request a [CVE](https://cveform.mitre.org/) and open an upstream
> -      [bug](https://www.qemu.org/contribute/report-a-bug/)
> -    - Create an upstream fix patch annotated with
> -        - CVE-ID
> -        - Link to an upstream bugzilla
> -        - Reported-by, Tested-by etc. tags
> -    - Once the patch is merged, close the upstream bug with a link to the
> -      commit
> -        - Fixed in: <commit hash/link>
> -
> -* Above security lists are operated by select analysts, maintainers and/or
> -  representatives from downstream communities.
> -
> -* List members follow a **responsible disclosure** policy. Any non-public
> -  information you share about security issues, is kept confidential within
> -  members of the QEMU security team and a minimal supporting staff in their
> -  affiliated companies. Such information will not be disclosed to third party
> -  organisations/individuals without prior permission from the reporter(s).
> -
> -* We aim to process security issues within maximum of **60 days**. That is not
> -  to say that issues will remain private for 60 days, nope. After the triaging
> -  step above
> -    - If severity of the issue is sufficiently low, an upstream public bug
> -      will be created immediately.
> -    - If severity of the issue requires co-ordinated disclosure at a future
> -      date, then the embargo process below is followed, and upstream bug will
> -      be opened at the end of the embargo period.
> -
> -  This will allow upstream contributors to create, test and track fix patch(es).
> -
> -### Publication embargo
> -
> -* If a security issue is reported that is not already public and its severity
> -  requires coordinated disclosure, then an embargo date will be set and
> -  communicated to the reporter(s).
> -
> -* Embargo periods will be negotiated by mutual agreement between reporter(s),
> -  members of the security list and other relevant parties to the problem.
> -  The preferred embargo period is upto [2
> -  weeks](https://oss-security.openwall.org/wiki/mailing-lists/distros).
> -  However, longer embargoes may be negotiated if the severity of the issue
> -  requires it.
> -
> -* Members of the security list agree not to publicly disclose any details of
> -  an embargoed security issue until its embargo date expires.
> -
> -### CVE allocation
> -
> -Each security issue is assigned a [CVE](https://cveform.mitre.org/) number.
> -The CVE number is allocated by one of the vendor security engineers on the
> -security list.
> -
> -## When to contact the QEMU Security List
> -
> -You should contact the Security List if:
> -* You think there may be a security vulnerability in QEMU.
> -* You are unsure about how a known vulnerability affects QEMU.
> -* You can contact us in English. We are unable to respond in other languages.
> -
> -## When *not* to contact the QEMU Security List
> -* You have not yet performed human review of the output of an automated tool.
> -* You need assistance in a language other than English.
> -* You require technical assistance (for example, "how do I configure QEMU?").
> -* You need help upgrading QEMU due to security alerts.
> -* Your issue is not security related.
> -
> -## How impact and severity of a bug is decided
> -
> -**Security criterion:**
> -    -> [https://www.qemu.org/docs/master/system/security.html](https://www.qemu.org/docs/master/system/security.html)
> -
> -All security issues in QEMU are not equal. Based on the parts of the QEMU
> -sources wherein the bug is found, its impact and severity could vary.
> -
> -In particular, QEMU is used in many different scenarios; some of them assume
> -that the guest is trusted, some of them don't. General considerations to triage
> -QEMU issues and decide whether a configuration is security sensitive include:
> -
> -* Is there any feasible way for a malicious party to exploit this flaw and
> -  cause real damage? (e.g. from a guest or via downloadable images)
> -* Does the flaw require access to the management interface? Would the
> -  management interface be accessible in the scenario where the flaw could cause
> -  real damage?
> -* Is QEMU used in conjunction with a hypervisor (as opposed to TCG binary
> -  translation)?
> -* Is QEMU used to offer virtualised production services, as opposed to usage
> -  as a development platform?
> -
> -Whenever some or all of these questions have negative answers, what appears to
> -be a major security flaw might be considered of low severity because it could
> -only be exercised in use cases where QEMU and everything interacting with it is
> -trusted.
> -
> -For example, consider upstream commit [9201bb9 "sdhci.c: Limit the maximum
> -block size"](https://gitlab.com/qemu-project/qemu/-/commit/9201bb9), an of out of
> -bounds (OOB) memory access (ie. buffer overflow) issue that was found and fixed
> -in the SD Host Controller emulation (hw/sd/sdhci.c).
> -
> -On the surface, this bug appears to be a genuine security flaw, with potentially
> -severe implications. But digging further down, there are only two ways to use
> -SD Host Controller emulation, one is via 'sdhci-pci' interface and the other
> -is via 'generic-sdhci' interface.
> -
> -Of these two, the 'sdhci-pci' interface had actually been disabled by default
> -in the upstream QEMU releases (commit [1910913 "sdhci: Make device "sdhci-pci"
> -unavailable with -device"](https://gitlab.com/qemu-project/qemu/-/commit/1910913)
> -at the time the flaw was reported; therefore, guests could not possibly use
> -'sdhci-pci' for any purpose.
> -
> -The 'generic-sdhci' interface, instead, had only one user in 'Xilinx Zynq
> -Baseboard emulation' (hw/arm/xilinx_zynq.c). Xilinx Zynq is a programmable
> -systems on chip (SoC) device. While QEMU does emulate this device, in practice
> -it is used to facilitate cross-platform developmental efforts, i.e. QEMU is
> -used to write programs for the SoC device. In such developer environments, it
> -is generally assumed that the guest is trusted.
> -
> -And thus, this buffer overflow turned out to be a security non-issue.
> +## How to disclosure a potential issues
> +
> +**The QEMU project no longer accepts security issue disclosures via email.**
> +
> +New disclosures must follow the [report a bug](report-a-bug.html)
> +process to file a GitLab work item for each potential issue, ***marking
> +it as "*confidential*" prior to submission.***
> +
> +If unsure of the security implications of an issue, err on the side
> +of caution and mark it as "*confidential*" initially.
> +
> +## Handling of disclosures
> +
> +Disclosures made via "*confidential*" GitLab issues are visible to, and
> +may be handled by, any QEMU subsystem maintainer whom has a GitLab
> +account [associated with the Reporter role in the project](https://gitlab.com/qemu-project/qemu/-/project_members).
> +Triage may also be performed by one or more automated tools and/or
> +AI agents run by the project that have been granted access to the
> +issue tracker.
> +
> +The first task upon receiving a disclosure is to evaluate eligibility
> +to follow the security triage process.
> +
> +* Disclosures affecting code / features evaluated to fall under the
> +[non-virtualization use case](
> +https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case),
> +will generally not be eligible for handling as a security flaw.
> +Such disclosures should be immediately switched to the public
> +bug report process by removing the "*confidential*" marker.
> +
> +* Disclosures affecting code / features evaluated to fall under the
> +[virtualization use case](
> +https://www.qemu.org/docs/master/system/security.html#virtualization-use-case),
> +will be handled under a lightweight security triage process which
> +emphasizes getting a fix merged to the latest development branch
> +as quickly as possible.
> +
> +Any disclosure which gets switched to the public bug report process
> +will be fixed at the discretion of the maintainer, if and when time
> +allows.
> +
> +In all cases reporters are encouraged to develop and propose patches
> +for issues themselves at time of disclosure, to speed resolution.
> +
> +**NOTE:** The QEMU project policy is that all security disclosures received
> +using GitLab "*confidential*" issues **will eventually be made public**. Any
> +information that the reporter considers to be be sensitive / private **must**
> +be scrubbed before disclosure.
> +
> +## Triage process
> +
> + * A maintainer will evaluate the circumstances of the issue
> +   to determine if it can be misused for malicious purposes.
> +
> + * If there is no potential for meaningful exploit, the disclosure
> +   should be switched to the public bug report process by removing
> +   the "*confidential*" marker.
> +
> + * If confirmed as a security flaw, a maintainer will request
> +   add the **"cve::required"** GitLab label to the GitLab work item,
> +   which indicates the need for a CNA to allocate a CVE.
> +
> + * The maintainer(s) will develop and/or review patch(es)
> +   for the issue privately, optionally attaching work in
> +   progress fixes to the GitLab issues. All patches must
> +   include the issue URL in the commit message(s).
> +
> + * When a CVE is allocated, it will be recorded as a comment on
> +   the GitLab issue, and the **"cve::requested"** label replaced by
> +   the **"cve::assigned"** label.
> +
> + * The maintainer(s) will update the commit message(s) to include
> +   the assigned CVE. If multiple commits are required to fix an
> +   issue the CVE must be included in the final commit in the
> +   series, and may optionally be included in all prior commits.
> +
> + * When the maintainer(s) are satisfied that the patch(es) are
> +   suitable to propose for merge, they must be submitted to
> +   the qemu-devel mailing list, and follow the normal process
> +   for merge henceforth.
> +
> + * At the time the proposed patches are sent to qemu-devel, the
> +   maintainers should remove the "*confidential*" marker from the
> +   GitLab issue.
> +
> + * When the patch is merged into the current development
> +   branch the issue must be closed. This should usually happen
> +   automatically if the git commits referenced the GitLab issue
> +   URL in [the normal format](https://docs.gitlab.com/user/project/issues/managing_issues/#default-closing-pattern).
> +
> +The QEMU project currently co-ordinates with Red Hat for CVE
> +assignment, in its role as the [CNA of last resort for OSS projects](
> +https://www.cve.org/PartnerInformation/ListofPartners/partner/redhat).
> +
> +## Embargo policy
> +
> +The QEMU project policy is to limit the time that a disclosure has the
> +"*confidential*" marker applied strictly to the minimum required to develop
> +and publish a suitable patch and allocate a CVE.
> +
> +Given the widespread use of AI/LLM based agents for security auditing,
> +as well as ongoing use of traditional fuzzing and static analyis
> +tools, the QEMU maintainers consider that any disclosure originating
> +from automated tools is highly likely to be independently re-discovered,
> +potentially many times over in a very short timeframe.
> +
> +Thus the QEMU maintainers will generally reject requests for arbitrary
> +embargos unless high severity, extenuating circumstances can be
> +demonstrated.
> +
> +If a patch for a confirmed security issue cannot be developed by a
> +maintainer in a reasonable time, the maintainers may choose to make
> +a disclosure public without having a patch available. This approach
> +should only be taken for issues judged to have low severity.
> -- 
> 2.54.0