A DMA reentrancy issue was found in the EHCI controller emulation of QEMU. From https://gitlab.com/qemu-project/qemu/-/issues/541: """ When EHCI tries to transfer the USB packets, it doesn't check if the Buffer Pointer is overlapped with its MMIO region. So crafted content may be written to the controller's registers and trigger actions like reset, but the device is still transferring packets. """ This flaw could enable a malicious guest to crash QEMU, resulting in a denial of service condition, or potentially execute arbitrary code within the context of the QEMU process on the host. For more information (stack trace, reproducer) see the aforementioned upstream issue.
A fix is in the works for the whole class of DMA MMIO reentrancy issues: https://gitlab.com/qemu-project/qemu/-/issues/556 Patchset by Philippe Mathieu-Daudé: https://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg03692.html
Created qemu tracking bugs for this issue: Affects: epel-7 [bug 1999235] Affects: fedora-all [bug 1999234]
In reply to comment #0: > This flaw could enable a malicious guest to crash QEMU, resulting in a > denial of service condition, or potentially execute arbitrary code within > the context of the QEMU process on the host. While QEMU is an essential component in virtualization environments, it is not intended to be used directly on RHEL 8 systems due to security concerns. In other words, using qemu-kvm commands is not currently supported by Red Hat (https://access.redhat.com/solutions/408653). It is highly recommended to interact with QEMU by using libvirt, which provides several isolation mechanisms to realize guest isolation and the principle of least privilege. For example, the fundamental isolation mechanism is that QEMU processes on the host are run as unprivileged users. Also, the libvirtd daemon sets up additional sandbox around QEMU by leveraging SELinux and sVirt protection for QEMU guests, which further limits the potential damage in case of guest-to-host escape scenario. The impact of this flaw is limited (Moderate) under such circumstances.
For a *very good* description of this class of bugs, see this post by Peter Maydell: https://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg03927.html.
In reply to comment #2: > Patchset by Philippe Mathieu-Daudé: > https://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg03692.html Updated version: https://lists.nongnu.org/archive/html/qemu-devel/2021-12/msg02356.html
(In reply to Mauro Matteo Cascella from comment #8) > In reply to comment #2: > > Patchset by Philippe Mathieu-Daudé: > > https://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg03692.html > > Updated version: > https://lists.nongnu.org/archive/html/qemu-devel/2021-12/msg02356.html Looks like patches from this series have landed in qemu-7.0: 1/3: 2c89b5af5e72ab8c9d544c6e30399528b2238827 2/3: 58e74682baf4e1ad26b064d8c02e5bc99c75c5d9 3/3: 3ab6fdc91b72e156da22848f0003ff4225690ced
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:7967 https://access.redhat.com/errata/RHSA-2022:7967
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-3750
This was eventually fixed via commit https://gitlab.com/qemu-project/qemu/-/commit/a2e1753b8054344f32cf94f31c6399a58794a380.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2023:6980 https://access.redhat.com/errata/RHSA-2023:6980
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Extended Update Support Via RHSA-2024:0404 https://access.redhat.com/errata/RHSA-2024:0404
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:0569 https://access.redhat.com/errata/RHSA-2024:0569