Bug 1998514 (CVE-2021-3748)
| Summary: | CVE-2021-3748 QEMU: virtio-net: heap use-after-free in virtio_net_receive_rcu | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Mauro Matteo Cascella <mcascell> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | berrange, carnil, cfergeau, crobinso, dbecker, jen, jferlan, jforbes, jjoyce, jmaloy, jschluet, knoel, lhh, lkundrak, lpeer, m.a.young, mburns, mkenneth, mrezanin, mst, ondrejj, pbonzini, philmd, ribarry, rjones, sclewis, slinaber, tuxmealux+redhatbz, virt-maint, virt-maint |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm 6.2.0 | Doc Type: | If docs needed, set a value |
| Doc Text: |
A use-after-free vulnerability was found in the virtio-net device of QEMU. It could occur when the descriptor's address belongs to the non direct access region, due to num_buffers being set after the virtqueue elem has been unmapped. A malicious guest could use this flaw to crash QEMU, resulting in a denial of service condition, or potentially execute code on the host with the privileges of the QEMU process.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-03 14:07:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1999211, 1999212, 1999213, 1999221, 1999222, 1999223, 1999224, 2014569 | ||
| Bug Blocks: | 1997966, 2003975 | ||
|
Description
Mauro Matteo Cascella
2021-08-27 12:54:17 UTC
Hi Mauro, Could you please confirm if the described use-after-free is related to this [0] upstream bug? Cheers, Gianluca [0] https://gitlab.com/qemu-project/qemu/-/issues/535 Hi Gianluca, (In reply to Gianluca Gabrielli from comment #4) > Hi Mauro, > > Could you please confirm if the described use-after-free is related to this > [0] upstream bug? > > Cheers, > Gianluca > > [0] https://gitlab.com/qemu-project/qemu/-/issues/535 At first glance it doesn't seem to be related: this is a virtio-net specific issue while the assertion failure in #535 is triggered via e1000e. iov_from_buf_full is involved in both cases, but I think they are different issues. Note: bug summary and comment#0 were edited to make it clear that this originates from virtio_net_receive_rcu (virtio-net). Created qemu tracking bugs for this issue: Affects: epel-7 [bug 1999212] Affects: fedora-all [bug 1999211] Created xen tracking bugs for this issue: Affects: fedora-all [bug 1999213] (In reply to Mauro Matteo Cascella from comment #5) > Hi Gianluca, > > (In reply to Gianluca Gabrielli from comment #4) > > Hi Mauro, > > > > Could you please confirm if the described use-after-free is related to this > > [0] upstream bug? > > > > Cheers, > > Gianluca > > > > [0] https://gitlab.com/qemu-project/qemu/-/issues/535 > > At first glance it doesn't seem to be related: this is a virtio-net specific > issue while the assertion failure in #535 is triggered via e1000e. > iov_from_buf_full is involved in both cases, but I think they are different > issues. > > Note: bug summary and comment#0 were edited to make it clear that this > originates from virtio_net_receive_rcu (virtio-net). Following up on that, as this is not the same as #535, do you know if this was reported upstream to qemu? Regards, Salvatore Hi Salvatore, In reply to comment #8: > Following up on that, as this is not the same as #535, do you know if this > was reported upstream to qemu? This was reported via qemu-security mailing list (https://www.qemu.org/contribute/security-process). As far as I can see, no upstream issue was created for this. The CVE is mentioned in the upstream patch by Jason Wang, though (see comment#0). In reply to comment #0: > A malicious guest could use this flaw to crash QEMU, resulting in a denial > of service condition, or potentially execute code on the host with the > privileges of the QEMU process. 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. This issue has been addressed in the following products: Advanced Virtualization for RHEL 8.4.0.Z Via RHSA-2021:4112 https://access.redhat.com/errata/RHSA-2021:4112 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-3748 This issue has been addressed in the following products: Advanced Virtualization for RHEL 8.2.1 Via RHSA-2021:5036 https://access.redhat.com/errata/RHSA-2021:5036 This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:1759 https://access.redhat.com/errata/RHSA-2022:1759 |