Bugzilla – Bug 1193914
VUL-0: CVE-2021-3611: qemu: intel-hda: segmentation fault due to stack overflow
Last modified: 2022-05-25 11:39:43 UTC
+++ This bug was initially created as a clone of Bug #1187529 +++ A KVM guest can crash qemu-kvm (likely with a stack overflow) when the guest has been started with the intel-hda device. According to the upstream ticket, the crash is due to a stack overflow. Upstream bug: https://bugs.launchpad.net/qemu/+bug/1907497 References: https://bugzilla.redhat.com/show_bug.cgi?id=1973784 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3611
As you can read in bsc#1187529#c18, we backported the wrong security patch to mitigate CVE-2021-3611. In the other hand, we fixed another security bug that still not have a CVE ID assigned. A patch for CVE-2021-3611 has not been approved yet by the upstream [1], there are some under review right now. As soon as it will be patched at upstream I will update this issue. [0] https://bugzilla.suse.com/show_bug.cgi?id=1187529#c18 [1] https://gitlab.com/qemu-project/qemu/-/issues/542
(In reply to Gianluca Gabrielli from comment #1) > A patch for CVE-2021-3611 has not been approved yet by the upstream [1], > there are some under review right now. As soon as it will be patched at > upstream I will update this issue. > > > [0] https://bugzilla.suse.com/show_bug.cgi?id=1187529#c18 > [1] https://gitlab.com/qemu-project/qemu/-/issues/542 Just as an update, this (AFAIUI) should be addressed by: https://lore.kernel.org/qemu-devel/20211218160912.1591633-1-philmd@redhat.com/ Which is still not upstream.
Upstream patch was merged a couple weeks ago: https://gitlab.com/qemu-project/qemu/-/commit/79fa99831debc9782087e834382c577215f2f511
Tracking as affected: - SUSE:SLE-12-SP2:Update/qemu - SUSE:SLE-12-SP3:Update/qemu - SUSE:SLE-12-SP4:Update/qemu - SUSE:SLE-12-SP5:Update/qemu - SUSE:SLE-15:Update/qemu - SUSE:SLE-15-SP1:Update/qemu - SUSE:SLE-15-SP2:Update/qemu - SUSE:SLE-15-SP3:Update/qemu - SUSE:SLE-15-SP4:Update/qemu
(In reply to Gabriele Sonnu from comment #3) > Upstream patch was merged a couple weeks ago: > > https://gitlab.com/qemu-project/qemu/-/commit/ > 79fa99831debc9782087e834382c577215f2f511 > So, at a first look, this comes with be5a8cf347d0c47ee3e933dde075526fd8bd5c40 ("hw/audio/intel-hda: Do not ignore DMA overrun errors") as a dependency. I need to check further, but we may also need: softmmu/physmem: Introduce MemTxAttrs::memory field and MEMTX_ACCESS_ERROR softmmu/physmem: Simplify flatview_write and address_space_access_valid Anyway, be5a8cf347d0c47ee3e933dde075526fd8bd5c40, in its turn, depends on the following upstream commits, present only in QEMU 7.0 (so they'd *all* need to be backported to 15-SP4 and earlier): pci: Let ld*_pci_dma() propagate MemTxResult pci: Let st*_pci_dma() propagate MemTxResult pci: Let ld*_pci_dma() take MemTxAttrs argument pci: Let st*_pci_dma() take MemTxAttrs argument dma: Let ld*_dma() propagate MemTxResult dma: Let st*_dma() propagate MemTxResult dma: Let ld*_dma() take MemTxAttrs argument dma: Let st*_dma() take MemTxAttrs argument dma: Let dma_buf_rw() propagate MemTxResult dma: Let dma_buf_read() take MemTxAttrs argument dma: Let dma_buf_write() take MemTxAttrs argument dma: Let dma_buf_rw() take MemTxAttrs argument pci: Let pci_dma_rw() take MemTxAttrs argument dma: Have dma_buf_read() / dma_buf_write() take a void pointer dma: Have dma_buf_rw() take a void pointer dma: Let dma_memory_map() take MemTxAttrs argument dma: Let dma_memory_read/write() take MemTxAttrs argument dma: Let dma_memory_rw() take MemTxAttrs argument dma: Let dma_memory_rw_relaxed() take MemTxAttrs argument dma: Let dma_memory_set() take MemTxAttrs argument dma: Let dma_memory_valid() take MemTxAttrs argument The vulnerability has a bit of an impact (score 6.5 MEDIUM, https://nvd.nist.gov/vuln/detail/CVE-2021-3611), so I'll give it a try, at least to backporting to 15-SP4 (which is QEMU 6.2). Let's, however, start to think at what will happen if backporting to QEMU earlier than 6.0 or 5.2 reveals to be practically impossible.
(In reply to Gabriele Sonnu from comment #4) > Tracking as affected: > > - SUSE:SLE-12-SP2:Update/qemu > - SUSE:SLE-12-SP3:Update/qemu > - SUSE:SLE-12-SP4:Update/qemu > - SUSE:SLE-12-SP5:Update/qemu > - SUSE:SLE-15:Update/qemu > - SUSE:SLE-15-SP1:Update/qemu > - SUSE:SLE-15-SP2:Update/qemu > - SUSE:SLE-15-SP3:Update/qemu > - SUSE:SLE-15-SP4:Update/qemu One thing: do we know if this is actually accurate? https://bugzilla.redhat.com/show_bug.cgi?id=1973784#c3 If yes, this would limit the need to backport only to QEMU >= 5.0, which means: - SUSE:SLE-15-SP4:Update/qemu - SUSE:SLE-15-SP3:Update/qemu How has the above list of affected codestreams been put together?
Hi Dario, I read those resources and came to the same conclusion, ie this specific issue only should affect QEMU > 5.0 ie 15SP3 and 15SP4, if we didn't by any chance backport a9d8ba2be58e067bdfbff830eb9ff438d8db7f10 thus introducing the issue to older QEMUs (which being about intel-hda, I would not think so).
(In reply to Claudio Fontana from comment #7) > Hi Dario, I read those resources and came to the same conclusion, > ie this specific issue only should affect QEMU > 5.0 ie 15SP3 and 15SP4, > > if we didn't by any chance backport a9d8ba2be58e067bdfbff830eb9ff438d8db7f10 > thus introducing the issue to older QEMUs (which being about intel-hda, I > would not think so). > Exactly. My doubt comes from Comment 6 there: https://bugzilla.redhat.com/show_bug.cgi?id=1973784#c6 I.e., it says: "This bug turned out to be a manifestation of a well-known problem ("DMA reentrancy")". Does that mean "This bug was introduced in a9d8ba2be58e067bdfbff830eb9ff438d8db7f10, and is a manifestation of a well-known problem etc etc". Or does it mean: "This bug was not introduced by a9d8ba2be58e067bdfbff830eb9ff438d8db7f10, and is instead a manifestation of a well-known problem etc etc"?
(In reply to Dario Faggioli from comment #8) > (In reply to Claudio Fontana from comment #7) > > Hi Dario, I read those resources and came to the same conclusion, > > ie this specific issue only should affect QEMU > 5.0 ie 15SP3 and 15SP4, > > > > if we didn't by any chance backport a9d8ba2be58e067bdfbff830eb9ff438d8db7f10 > > thus introducing the issue to older QEMUs (which being about intel-hda, I > > would not think so). > > > Exactly. My doubt comes from Comment 6 there: > https://bugzilla.redhat.com/show_bug.cgi?id=1973784#c6 > > I.e., it says: "This bug turned out to be a manifestation of a well-known > problem ("DMA reentrancy")". > > Does that mean "This bug was introduced in > a9d8ba2be58e067bdfbff830eb9ff438d8db7f10, and is a manifestation of a > well-known problem etc etc". > > Or does it mean: "This bug was not introduced by > a9d8ba2be58e067bdfbff830eb9ff438d8db7f10, and is instead a manifestation of > a well-known problem etc etc"? In my reading the "manifestation of a well-known problem" is a reference to the fact that this bug happened because of an underlying design issue in QEMU. This issue can be solved with the available patches. The underlying design problem that makes these sort of issues easier to happen is I think: https://gitlab.com/qemu-project/qemu/-/issues/556
(In reply to Claudio Fontana from comment #10) > (In reply to Dario Faggioli from comment #8) > > (In reply to Claudio Fontana from comment #7) > > > Hi Dario, I read those resources and came to the same conclusion, > > > ie this specific issue only should affect QEMU > 5.0 ie 15SP3 and 15SP4, > > > > > > if we didn't by any chance backport a9d8ba2be58e067bdfbff830eb9ff438d8db7f10 > > > thus introducing the issue to older QEMUs (which being about intel-hda, I > > > would not think so). > > > > > Exactly. My doubt comes from Comment 6 there: > > https://bugzilla.redhat.com/show_bug.cgi?id=1973784#c6 > > > > I.e., it says: "This bug turned out to be a manifestation of a well-known > > problem ("DMA reentrancy")". > > > > Does that mean "This bug was introduced in > > a9d8ba2be58e067bdfbff830eb9ff438d8db7f10, and is a manifestation of a > > well-known problem etc etc". > > > > Or does it mean: "This bug was not introduced by > > a9d8ba2be58e067bdfbff830eb9ff438d8db7f10, and is instead a manifestation of > > a well-known problem etc etc"? > > In my reading the "manifestation of a well-known problem" is a reference to > the fact that this bug happened because of an underlying design issue in > QEMU. > > This issue can be solved with the available patches. Sorry, this is a bit difficult to read. What I mean here is, this bugzilla can be solved with the available patches, for the underlying design issue in QEMU there is no solution yet, but out of scope for this specific request. > > The underlying design problem that makes these sort of issues easier to > happen is I think: > > https://gitlab.com/qemu-project/qemu/-/issues/556