Security Process

Please report any suspected security issue in QEMU to the security mailing list at:

To report an issue via GPG encrypted email, please send it to the Red Hat Product Security team at:

Note: after the triage, encrypted issue details shall be sent to the upstream ‘qemu-security’ mailing list for archival purposes.

How to report an issue:

How we respond:

Publication embargo

CVE allocation

Each security issue is assigned a CVE 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:

When not to contact the QEMU Security List

How impact and severity of a bug is decided

Security criterion: -> 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:

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”, 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” 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.