QEMU takes security very seriously, and we aim to take immediate action to address serious security-related problems that involve our product.
Please report any suspected security vulnerability in QEMU to the following addresses. You can use GPG keys for respective receipients to communicate with us securely. If you do, please upload your GPG public key or supply it to us in some other way, so that we can communicate to you in a secure way, too! Please include the tag [QEMU-SECURITY] on the subject line to help us identify your message as security-related.
|Contact Person(s)||Contact Address||Company||GPG key||GPG key fingerprint|
|Michael S. Tsirkinemail@example.com||Red Hat Inc.||[GPG key ]||Fingerprint=0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67|
|Petr Matousekfirstname.lastname@example.org||Red Hat Inc.||[GPG key ]||Fingerprint=8107 AF16 A416 F9AF 18F3 D874 3E78 6F42 C449 77CA|
|Stefano Stabelliniemail@example.com||Independent||[GPG key ]||Fingerprint=D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90|
|Security Response Teamfirstname.lastname@example.org||Red Hat Inc.||[GPG key]|
|Michael Rothemail@example.com||IBM||[GPG key ]||Fingerprint=CEAC C9E1 5534 EBAB B82D 3FA0 3353 C9CE F108 B584|
|Prasad J Panditfirstname.lastname@example.org||Red Hat Inc.||[GPG key]||Fingerprint=47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F|
How to Contact Us Securely
We use a GNU Privacy Guard (GnuPG or GPG) keys to secure communications. Mail sent to members of the list can be encrypted with public keys of all members of the list. We expect to change some of the keys we use from time to time. Should we change the key, the previous keys will be revoked.
How we respond
Maintainers listed on the security reporting list operate a policy of responsible disclosure. As such they agree that any information you share with them about security issues that are not public knowledge is kept confidential within respective affiliated companies. It is not passed on to any third-party, including Xen Security Project, without your permission.
Email sent to us is read and acknowledged with a non-automated response. For issues that are complicated and require significant attention, we will open an investigation and keep you informed of our progress. We might take one or more of the following steps:
As a security issue reported, that is not already publically disclosed elsewhere, has an embargo date assigned and communicated to reporter. Embargo periods will be negotiated by mutual agreement between members of the security team and other relevant parties to the problem. Members of the security contact list agree not to publically disclose any details of the security issue until the embargo date expires.
An security issue is assigned with a CVE number. The CVE numbers will usually be allocated by one of the vendor security engineers on the security contact list.
When to Contact the QEMU Security Contact List
You should contact the Security Contact 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 Contact List
- 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
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 fact, at times, what appears to be a genuine security flaw, might not be considered so because it lies in the generally trusted sources and/or configurations. Ie. It can only be exercised in use cases where QEMU and everything interacting with it is trusted.
For example, recently a genuine case of out of bounds (OOB) memory access (ie. buffer overflow) issue was found and fixed in the SD Host Controller emulation(hw/sd/sdhci.c).
Upstream commit 9201bb9 "sdhci.c: Limit the maximum block size"
Prima facie, this bug appears to be a genuine security flaw, with potentially severe implications. But digging further down, it shows that 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 is relatively new and has been disabled by default in the upstream QEMU releases, so guests could not possibly use it for any purpose.
The 'generic-sdhci' interface has only one user in 'Xilinx Zynq Baseboard emulation' (ie. hw/arm/xilinx_zynq.c). Xilinx Zynq is a programmable systems on chip (SoC) device.
While upstream QEMU does emulate this device, in practice it is used to facilitate cross-platform developmental efforts. I.e. using QEMU emulation to write programs for the SoC device. In such developer environments, it is assumed that the guest is generally trusted.
And thus, this seemingly genuine buffer overflow issue turned out to be a security non-issue.
General considerations: for triaging QEMU issues to be security OR non-security
- Is QEMU used in conjunction with a hypervisor...?
- Is QEMU used to run virtualised production environments...?
- Is QEMU used to offer virtualised production services? OR is it used as development platform...?
- Is there any feasible way for a malicious party to exploit this flaw and cause real damage...?
- Is the flaw found in the gdbstub server source...?
- Does QEMU configuration/setup has any untrusted users...?
What to Send to the QEMU Security Contact List
Please provide as much information about your system and the issue as possible when contacting the list.