Package: release.debian.org Severity: normal Tags: bullseye User: release.debian....@packages.debian.org Usertags: pu X-Debbugs-Cc: q...@packages.debian.org, m...@tls.msk.ru Control: affects -1 + src:qemu
Various low severity security issues in qemu, debdiff below. I've tested this on a Bullseye ganeti cluster using the updated qemu. Cheers, Moritz diff -Nru qemu-5.2+dfsg/debian/changelog qemu-5.2+dfsg/debian/changelog --- qemu-5.2+dfsg/debian/changelog 2022-05-04 21:50:01.000000000 +0200 +++ qemu-5.2+dfsg/debian/changelog 2023-09-04 16:11:35.000000000 +0200 @@ -1,3 +1,19 @@ +qemu (1:5.2+dfsg-11+deb11u3) bullseye; urgency=medium + + * CVE-2021-20196 (Closes: #984453) + * CVE-2023-0330 (Closes: #1029155) + * CVE-2023-1544 (Closes: #1034179) + * CVE-2023-3354 + * CVE-2021-3930 + * CVE-2023-3180 + * CVE-2021-20203 (Closes: #984452) + * CVE-2021-3507 (Closes: #987410) + * CVE-2020-14394 (Closes: #979677) + * CVE-2023-3301 + * CVE-2022-0216 (Closes: #1014590) + + -- Moritz Mühlenhoff <j...@debian.org> Mon, 04 Sep 2023 16:11:35 +0200 + qemu (1:5.2+dfsg-11+deb11u2) bullseye-security; urgency=medium * virtio-net-fix-map-leaking-on-error-during-receive-CVE-2022-26353.patch diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2020-14394.patch qemu-5.2+dfsg/debian/patches/CVE-2020-14394.patch --- qemu-5.2+dfsg/debian/patches/CVE-2020-14394.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2020-14394.patch 2023-08-22 12:42:56.000000000 +0200 @@ -0,0 +1,67 @@ +From effaf5a240e03020f4ae953e10b764622c3e87cc Mon Sep 17 00:00:00 2001 +From: Thomas Huth <th...@redhat.com> +Date: Thu, 4 Aug 2022 15:13:00 +0200 +Subject: [PATCH] hw/usb/hcd-xhci: Fix unbounded loop in + xhci_ring_chain_length() (CVE-2020-14394) + +The loop condition in xhci_ring_chain_length() is under control of +the guest, and additionally the code does not check for failed DMA +transfers (e.g. if reaching the end of the RAM), so the loop there +could run for a very long time or even forever. Fix it by checking +the return value of dma_memory_read() and by introducing a maximum +loop length. + +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/646 +Message-Id: <20220804131300.96368-1-th...@redhat.com> +Reviewed-by: Mauro Matteo Cascella <mcasc...@redhat.com> +Acked-by: Gerd Hoffmann <kra...@redhat.com> +Signed-off-by: Thomas Huth <th...@redhat.com> +--- + hw/usb/hcd-xhci.c | 23 +++++++++++++++++++---- + 1 file changed, 19 insertions(+), 4 deletions(-) + +--- qemu-5.2+dfsg.orig/hw/usb/hcd-xhci.c ++++ qemu-5.2+dfsg/hw/usb/hcd-xhci.c +@@ -21,6 +21,7 @@ + + #include "qemu/osdep.h" + #include "qemu/timer.h" ++#include "qemu/log.h" + #include "qemu/module.h" + #include "qemu/queue.h" + #include "migration/vmstate.h" +@@ -720,9 +721,13 @@ static int xhci_ring_chain_length(XHCISt + bool control_td_set = 0; + uint32_t link_cnt = 0; + +- while (1) { ++ do { + TRBType type; +- dma_memory_read(xhci->as, dequeue, &trb, TRB_SIZE); ++ if (dma_memory_read(xhci->as, dequeue, &trb, TRB_SIZE) != MEMTX_OK) { ++ qemu_log_mask(LOG_GUEST_ERROR, "%s: DMA memory access failed!\n", ++ __func__); ++ return -1; ++ } + le64_to_cpus(&trb.parameter); + le32_to_cpus(&trb.status); + le32_to_cpus(&trb.control); +@@ -756,7 +761,17 @@ static int xhci_ring_chain_length(XHCISt + if (!control_td_set && !(trb.control & TRB_TR_CH)) { + return length; + } +- } ++ ++ /* ++ * According to the xHCI spec, Transfer Ring segments should have ++ * a maximum size of 64 kB (see chapter "6 Data Structures") ++ */ ++ } while (length < TRB_LINK_LIMIT * 65536 / TRB_SIZE); ++ ++ qemu_log_mask(LOG_GUEST_ERROR, "%s: exceeded maximum tranfer ring size!\n", ++ __func__); ++ ++ return -1; + } + + static void xhci_er_reset(XHCIState *xhci, int v) diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2021-20196.patch qemu-5.2+dfsg/debian/patches/CVE-2021-20196.patch --- qemu-5.2+dfsg/debian/patches/CVE-2021-20196.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2021-20196.patch 2023-09-04 16:11:35.000000000 +0200 @@ -0,0 +1,61 @@ +Combined backport of + +From 1ab95af033a419e7a64e2d58e67dd96b20af5233 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <phi...@redhat.com> +Date: Wed, 24 Nov 2021 17:15:35 +0100 +Subject: [PATCH] hw/block/fdc: Kludge missing floppy drive to fix + CVE-2021-20196 + +and + +From b154791e7b6d4ca5cdcd54443484d97360bd7ad2 Mon Sep 17 00:00:00 2001 +From: =?utf8?q?Philippe=20Mathieu-Daud=C3=A9?= <phi...@redhat.com> +Date: Wed, 24 Nov 2021 17:15:34 +0100 +Subject: [PATCH] hw/block/fdc: Extract blk_create_empty_drive() + +--- qemu-5.2+dfsg.orig/hw/block/fdc.c ++++ qemu-5.2+dfsg/hw/block/fdc.c +@@ -61,6 +61,12 @@ + } while (0) + + ++/* Anonymous BlockBackend for empty drive */ ++static BlockBackend *blk_create_empty_drive(void) ++{ ++ return blk_new(qemu_get_aio_context(), 0, BLK_PERM_ALL); ++} ++ + /********************************************************/ + /* qdev floppy bus */ + +@@ -543,8 +549,7 @@ static void floppy_drive_realize(DeviceS + } + + if (!dev->conf.blk) { +- /* Anonymous BlockBackend for an empty drive */ +- dev->conf.blk = blk_new(qemu_get_aio_context(), 0, BLK_PERM_ALL); ++ dev->conf.blk = blk_create_empty_drive(); + ret = blk_attach_dev(dev->conf.blk, qdev); + assert(ret == 0); + +@@ -1360,7 +1365,19 @@ static FDrive *get_drv(FDCtrl *fdctrl, i + + static FDrive *get_cur_drv(FDCtrl *fdctrl) + { +- return get_drv(fdctrl, fdctrl->cur_drv); ++ FDrive *cur_drv = get_drv(fdctrl, fdctrl->cur_drv); ++ ++ if (!cur_drv->blk) { ++ /* ++ * Kludge: empty drive line selected. Create an anonymous ++ * BlockBackend to avoid NULL deref with various BlockBackend ++ * API calls within this model (CVE-2021-20196). ++ * Due to the controller QOM model limitations, we don't ++ * attach the created to the controller device. ++ */ ++ cur_drv->blk = blk_create_empty_drive(); ++ } ++ return cur_drv; + } + + /* Status A register : 0x00 (read-only) */ diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2021-20203.patch qemu-5.2+dfsg/debian/patches/CVE-2021-20203.patch --- qemu-5.2+dfsg/debian/patches/CVE-2021-20203.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2021-20203.patch 2023-08-21 18:25:41.000000000 +0200 @@ -0,0 +1,71 @@ +From d05dcd94aee88728facafb993c7280547eb4d645 Mon Sep 17 00:00:00 2001 +From: Prasad J Pandit <p...@fedoraproject.org> +Date: Sat, 30 Jan 2021 18:46:52 +0530 +Subject: [PATCH] net: vmxnet3: validate configuration values during activate + (CVE-2021-20203) + +While activating device in vmxnet3_acticate_device(), it does not +validate guest supplied configuration values against predefined +minimum - maximum limits. This may lead to integer overflow or +OOB access issues. Add checks to avoid it. + +Fixes: CVE-2021-20203 +Buglink: https://bugs.launchpad.net/qemu/+bug/1913873 +Reported-by: Gaoning Pan <p...@zju.edu.cn> +Signed-off-by: Prasad J Pandit <p...@fedoraproject.org> +Signed-off-by: Jason Wang <jasow...@redhat.com> +--- + hw/net/vmxnet3.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + + +--- qemu-5.2+dfsg.orig/hw/net/vmxnet3.c ++++ qemu-5.2+dfsg/hw/net/vmxnet3.c +@@ -1420,6 +1420,7 @@ static void vmxnet3_activate_device(VMXN + vmxnet3_setup_rx_filtering(s); + /* Cache fields from shared memory */ + s->mtu = VMXNET3_READ_DRV_SHARED32(d, s->drv_shmem, devRead.misc.mtu); ++ assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU); + VMW_CFPRN("MTU is %u", s->mtu); + + s->max_rx_frags = +@@ -1473,6 +1474,9 @@ static void vmxnet3_activate_device(VMXN + /* Read rings memory locations for TX queues */ + pa = VMXNET3_READ_TX_QUEUE_DESCR64(d, qdescr_pa, conf.txRingBasePA); + size = VMXNET3_READ_TX_QUEUE_DESCR32(d, qdescr_pa, conf.txRingSize); ++ if (size > VMXNET3_TX_RING_MAX_SIZE) { ++ size = VMXNET3_TX_RING_MAX_SIZE; ++ } + + vmxnet3_ring_init(d, &s->txq_descr[i].tx_ring, pa, size, + sizeof(struct Vmxnet3_TxDesc), false); +@@ -1483,6 +1487,9 @@ static void vmxnet3_activate_device(VMXN + /* TXC ring */ + pa = VMXNET3_READ_TX_QUEUE_DESCR64(d, qdescr_pa, conf.compRingBasePA); + size = VMXNET3_READ_TX_QUEUE_DESCR32(d, qdescr_pa, conf.compRingSize); ++ if (size > VMXNET3_TC_RING_MAX_SIZE) { ++ size = VMXNET3_TC_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->txq_descr[i].comp_ring, pa, size, + sizeof(struct Vmxnet3_TxCompDesc), true); + VMXNET3_RING_DUMP(VMW_CFPRN, "TXC", i, &s->txq_descr[i].comp_ring); +@@ -1524,6 +1531,9 @@ static void vmxnet3_activate_device(VMXN + /* RX rings */ + pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.rxRingBasePA[j]); + size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.rxRingSize[j]); ++ if (size > VMXNET3_RX_RING_MAX_SIZE) { ++ size = VMXNET3_RX_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->rxq_descr[i].rx_ring[j], pa, size, + sizeof(struct Vmxnet3_RxDesc), false); + VMW_CFPRN("RX queue %d:%d: Base: %" PRIx64 ", Size: %d", +@@ -1533,6 +1543,9 @@ static void vmxnet3_activate_device(VMXN + /* RXC ring */ + pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.compRingBasePA); + size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.compRingSize); ++ if (size > VMXNET3_RC_RING_MAX_SIZE) { ++ size = VMXNET3_RC_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->rxq_descr[i].comp_ring, pa, size, + sizeof(struct Vmxnet3_RxCompDesc), true); + VMW_CFPRN("RXC queue %d: Base: %" PRIx64 ", Size: %d", i, pa, size); diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2021-3507.patch qemu-5.2+dfsg/debian/patches/CVE-2021-3507.patch --- qemu-5.2+dfsg/debian/patches/CVE-2021-3507.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2021-3507.patch 2023-08-21 18:28:35.000000000 +0200 @@ -0,0 +1,81 @@ +From defac5e2fbddf8423a354ff0454283a2115e1367 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <phi...@redhat.com> +Date: Thu, 18 Nov 2021 12:57:32 +0100 +Subject: [PATCH] hw/block/fdc: Prevent end-of-track overrun (CVE-2021-3507) +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Per the 82078 datasheet, if the end-of-track (EOT byte in +the FIFO) is more than the number of sectors per side, the +command is terminated unsuccessfully: + +* 5.2.5 DATA TRANSFER TERMINATION + + The 82078 supports terminal count explicitly through + the TC pin and implicitly through the underrun/over- + run and end-of-track (EOT) functions. For full sector + transfers, the EOT parameter can define the last + sector to be transferred in a single or multisector + transfer. If the last sector to be transferred is a par- + tial sector, the host can stop transferring the data in + mid-sector, and the 82078 will continue to complete + the sector as if a hardware TC was received. The + only difference between these implicit functions and + TC is that they return "abnormal termination" result + status. Such status indications can be ignored if they + were expected. + +* 6.1.3 READ TRACK + + This command terminates when the EOT specified + number of sectors have been read. If the 82078 + does not find an I D Address Mark on the diskette + after the second· occurrence of a pulse on the + INDX# pin, then it sets the IC code in Status Regis- + ter 0 to "01" (Abnormal termination), sets the MA bit + in Status Register 1 to "1", and terminates the com- + mand. + +* 6.1.6 VERIFY + + Refer to Table 6-6 and Table 6-7 for information + concerning the values of MT and EC versus SC and + EOT value. + +* Table 6·6. Result Phase Table + +* Table 6-7. Verify Command Result Phase Table + +Fix by aborting the transfer when EOT > # Sectors Per Side. + +Cc: qemu-sta...@nongnu.org +Cc: Hervé Poussineau <hpous...@reactos.org> +Fixes: baca51faff0 ("floppy driver: disk geometry auto detect") +Reported-by: Alexander Bulekov <alx...@bu.edu> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/339 +Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com> +Message-Id: <20211118115733.4038610-2-phi...@redhat.com> +Reviewed-by: Hanna Reitz <hre...@redhat.com> +Signed-off-by: Kevin Wolf <kw...@redhat.com> +--- + hw/block/fdc.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- qemu-5.2+dfsg.orig/hw/block/fdc.c ++++ qemu-5.2+dfsg/hw/block/fdc.c +@@ -1724,6 +1724,14 @@ static void fdctrl_start_transfer(FDCtrl + int tmp; + fdctrl->data_len = 128 << (fdctrl->fifo[5] > 7 ? 7 : fdctrl->fifo[5]); + tmp = (fdctrl->fifo[6] - ks + 1); ++ if (tmp < 0) { ++ FLOPPY_DPRINTF("invalid EOT: %d\n", tmp); ++ fdctrl_stop_transfer(fdctrl, FD_SR0_ABNTERM, FD_SR1_MA, 0x00); ++ fdctrl->fifo[3] = kt; ++ fdctrl->fifo[4] = kh; ++ fdctrl->fifo[5] = ks; ++ return; ++ } + if (fdctrl->fifo[0] & 0x80) + tmp += fdctrl->fifo[6]; + fdctrl->data_len *= tmp; diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2021-3930.patch qemu-5.2+dfsg/debian/patches/CVE-2021-3930.patch --- qemu-5.2+dfsg/debian/patches/CVE-2021-3930.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2021-3930.patch 2023-08-21 18:15:07.000000000 +0200 @@ -0,0 +1,43 @@ +From b3af7fdf9cc537f8f0dd3e2423d83f5c99a457e8 Mon Sep 17 00:00:00 2001 +From: Mauro Matteo Cascella <mcasc...@redhat.com> +Date: Thu, 4 Nov 2021 17:31:38 +0100 +Subject: [PATCH] hw/scsi/scsi-disk: MODE_PAGE_ALLS not allowed in MODE SELECT + commands + +This avoids an off-by-one read of 'mode_sense_valid' buffer in +hw/scsi/scsi-disk.c:mode_sense_page(). + +Fixes: CVE-2021-3930 +Cc: qemu-sta...@nongnu.org +Reported-by: Alexander Bulekov <alx...@bu.edu> +Fixes: a8f4bbe2900 ("scsi-disk: store valid mode pages in a table") +Fixes: #546 +Reported-by: Qiuhao Li <qiuhao...@outlook.com> +Signed-off-by: Mauro Matteo Cascella <mcasc...@redhat.com> +Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> +--- + hw/scsi/scsi-disk.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- qemu-5.2+dfsg.orig/hw/scsi/scsi-disk.c ++++ qemu-5.2+dfsg/hw/scsi/scsi-disk.c +@@ -1100,6 +1100,7 @@ static int mode_sense_page(SCSIDiskState + uint8_t *p = *p_outbuf + 2; + int length; + ++ assert(page < ARRAY_SIZE(mode_sense_valid)); + if ((mode_sense_valid[page] & (1 << s->qdev.type)) == 0) { + return -1; + } +@@ -1441,6 +1442,11 @@ static int scsi_disk_check_mode_select(S + return -1; + } + ++ /* MODE_PAGE_ALLS is only valid for MODE SENSE commands */ ++ if (page == MODE_PAGE_ALLS) { ++ return -1; ++ } ++ + p = mode_current; + memset(mode_current, 0, inlen + 2); + len = mode_sense_page(s, page, &p, 0); diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2022-0216.patch qemu-5.2+dfsg/debian/patches/CVE-2022-0216.patch --- qemu-5.2+dfsg/debian/patches/CVE-2022-0216.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2022-0216.patch 2023-08-22 15:22:20.000000000 +0200 @@ -0,0 +1,37 @@ +Combined backport of + +From 6c8fa961da5e60f574bb52fd3ad44b1e9e8ad4b8 Mon Sep 17 00:00:00 2001 +From: Mauro Matteo Cascella <mcasc...@redhat.com> +Date: Tue, 5 Jul 2022 22:05:43 +0200 +Subject: [PATCH] scsi/lsi53c895a: fix use-after-free in lsi_do_msgout + (CVE-2022-0216) + +and + +From 4367a20cc442c56b05611b4224de9a61908f9eac Mon Sep 17 00:00:00 2001 +From: Mauro Matteo Cascella <mcasc...@redhat.com> +Date: Mon, 11 Jul 2022 14:33:16 +0200 +Subject: [PATCH] scsi/lsi53c895a: really fix use-after-free in lsi_do_msgout + (CVE-2022-0216) + +--- qemu-5.2+dfsg.orig/hw/scsi/lsi53c895a.c ++++ qemu-5.2+dfsg/hw/scsi/lsi53c895a.c +@@ -1029,8 +1029,9 @@ static void lsi_do_msgout(LSIState *s) + case 0x0d: + /* The ABORT TAG message clears the current I/O process only. */ + trace_lsi_do_msgout_abort(current_tag); +- if (current_req) { ++ if (current_req && current_req->req) { + scsi_req_cancel(current_req->req); ++ current_req = NULL; + } + lsi_disconnect(s); + break; +@@ -1056,6 +1057,7 @@ static void lsi_do_msgout(LSIState *s) + /* clear the current I/O process */ + if (s->current) { + scsi_req_cancel(s->current->req); ++ current_req = NULL; + } + + /* As the current implemented devices scsi_disk and scsi_generic diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2023-0330.patch qemu-5.2+dfsg/debian/patches/CVE-2023-0330.patch --- qemu-5.2+dfsg/debian/patches/CVE-2023-0330.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2023-0330.patch 2023-08-21 17:06:43.000000000 +0200 @@ -0,0 +1,66 @@ +From e49884a90987744ddb54b2fadc770633eb6a4d62 Mon Sep 17 00:00:00 2001 +From: Thomas Huth <th...@redhat.com> +Date: Mon, 22 May 2023 11:10:11 +0200 +Subject: [PATCH] hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI + controller (CVE-2023-0330) + +We cannot use the generic reentrancy guard in the LSI code, so +we have to manually prevent endless reentrancy here. The problematic +lsi_execute_script() function has already a way to detect whether +too many instructions have been executed - we just have to slightly +change the logic here that it also takes into account if the function +has been called too often in a reentrant way. + +The code in fuzz-lsi53c895a-test.c has been taken from an earlier +patch by Mauro Matteo Cascella. + +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1563 +Message-Id: <20230522091011.1082574-1-th...@redhat.com> +Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com> +Reviewed-by: Alexander Bulekov <alx...@bu.edu> +Signed-off-by: Thomas Huth <th...@redhat.com> +(cherry picked from commit b987718bbb1d0eabf95499b976212dd5f0120d75) +Signed-off-by: Michael Tokarev <m...@tls.msk.ru> + +--- qemu-5.2+dfsg.orig/hw/scsi/lsi53c895a.c ++++ qemu-5.2+dfsg/hw/scsi/lsi53c895a.c +@@ -1133,15 +1133,24 @@ static void lsi_execute_script(LSIState + uint32_t addr, addr_high; + int opcode; + int insn_processed = 0; ++ static int reentrancy_level; ++ ++ reentrancy_level++; + + s->istat1 |= LSI_ISTAT1_SRUN; + again: +- if (++insn_processed > LSI_MAX_INSN) { +- /* Some windows drivers make the device spin waiting for a memory +- location to change. If we have been executed a lot of code then +- assume this is the case and force an unexpected device disconnect. +- This is apparently sufficient to beat the drivers into submission. +- */ ++ /* ++ * Some windows drivers make the device spin waiting for a memory location ++ * to change. If we have executed more than LSI_MAX_INSN instructions then ++ * assume this is the case and force an unexpected device disconnect. This ++ * is apparently sufficient to beat the drivers into submission. ++ * ++ * Another issue (CVE-2023-0330) can occur if the script is programmed to ++ * trigger itself again and again. Avoid this problem by stopping after ++ * being called multiple times in a reentrant way (8 is an arbitrary value ++ * which should be enough for all valid use cases). ++ */ ++ if (++insn_processed > LSI_MAX_INSN || reentrancy_level > 8) { + if (!(s->sien0 & LSI_SIST0_UDC)) { + qemu_log_mask(LOG_GUEST_ERROR, + "lsi_scsi: inf. loop with UDC masked"); +@@ -1595,6 +1604,8 @@ again: + } + } + trace_lsi_execute_script_stop(); ++ ++ reentrancy_level--; + } + + static uint8_t lsi_reg_readb(LSIState *s, int offset) diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2023-1544.patch qemu-5.2+dfsg/debian/patches/CVE-2023-1544.patch --- qemu-5.2+dfsg/debian/patches/CVE-2023-1544.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2023-1544.patch 2023-08-21 18:11:25.000000000 +0200 @@ -0,0 +1,36 @@ +From 31c4b6fb0293e359f9ef8a61892667e76eea4c99 Mon Sep 17 00:00:00 2001 +From: Yuval Shaia <yuval.shaia...@gmail.com> +Date: Sun, 3 Apr 2022 12:52:34 +0300 +Subject: [PATCH] hw/pvrdma: Protect against buggy or malicious guest driver + +Guest driver might execute HW commands when shared buffers are not yet +allocated. +This could happen on purpose (malicious guest) or because of some other +guest/host address mapping error. +We need to protect againts such case. + +Fixes: CVE-2022-1050 + +Reported-by: Raven <wxhu...@gmail.com> +Signed-off-by: Yuval Shaia <yuval.shaia...@gmail.com> +Message-Id: <20220403095234.2210-1-yuval.shaia...@gmail.com> +Signed-off-by: Laurent Vivier <laur...@vivier.eu> +--- + hw/rdma/vmw/pvrdma_cmd.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- qemu-5.2+dfsg.orig/hw/rdma/vmw/pvrdma_cmd.c ++++ qemu-5.2+dfsg/hw/rdma/vmw/pvrdma_cmd.c +@@ -796,6 +796,12 @@ int pvrdma_exec_cmd(PVRDMADev *dev) + + dsr_info = &dev->dsr_info; + ++ if (!dsr_info->dsr) { ++ /* Buggy or malicious guest driver */ ++ rdma_error_report("Exec command without dsr, req or rsp buffers"); ++ goto out; ++ } ++ + if (dsr_info->req->hdr.cmd >= sizeof(cmd_handlers) / + sizeof(struct cmd_handler)) { + rdma_error_report("Unsupported command"); diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2023-3180.patch qemu-5.2+dfsg/debian/patches/CVE-2023-3180.patch --- qemu-5.2+dfsg/debian/patches/CVE-2023-3180.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2023-3180.patch 2023-08-21 18:16:19.000000000 +0200 @@ -0,0 +1,43 @@ +From 49f1e02bac166821c712534aaa775f50e1afe17f Mon Sep 17 00:00:00 2001 +From: zhenwei pi <pizhen...@bytedance.com> +Date: Thu, 3 Aug 2023 10:43:13 +0800 +Subject: [PATCH] virtio-crypto: verify src&dst buffer length for sym request + +For symmetric algorithms, the length of ciphertext must be as same +as the plaintext. +The missing verification of the src_len and the dst_len in +virtio_crypto_sym_op_helper() may lead buffer overflow/divulged. + +This patch is originally written by Yiming Tao for QEMU-SECURITY, +resend it(a few changes of error message) in qemu-devel. + +Fixes: CVE-2023-3180 +Fixes: 04b9b37edda("virtio-crypto: add data queue processing handler") +Cc: Gonglei <arei.gong...@huawei.com> +Cc: Mauro Matteo Cascella <mcasc...@redhat.com> +Cc: Yiming Tao <ta...@zju.edu.cn> +Signed-off-by: zhenwei pi <pizhen...@bytedance.com> +Message-Id: <20230803024314.29962-2-pizhen...@bytedance.com> +Reviewed-by: Michael S. Tsirkin <m...@redhat.com> +Signed-off-by: Michael S. Tsirkin <m...@redhat.com> +(cherry picked from commit 9d38a8434721a6479fe03fb5afb150ca793d3980) +Signed-off-by: Michael Tokarev <m...@tls.msk.ru> +--- + hw/virtio/virtio-crypto.c | 5 +++++ + 1 file changed, 5 insertions(+) + + +--- qemu-5.2+dfsg.orig/hw/virtio/virtio-crypto.c ++++ qemu-5.2+dfsg/hw/virtio/virtio-crypto.c +@@ -461,6 +461,11 @@ virtio_crypto_sym_op_helper(VirtIODevice + return NULL; + } + ++ if (unlikely(src_len != dst_len)) { ++ virtio_error(vdev, "sym request src len is different from dst len"); ++ return NULL; ++ } ++ + max_len = (uint64_t)iv_len + aad_len + src_len + dst_len + hash_result_len; + if (unlikely(max_len > vcrypto->conf.max_size)) { + virtio_error(vdev, "virtio-crypto too big length"); diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2023-3301.patch qemu-5.2+dfsg/debian/patches/CVE-2023-3301.patch --- qemu-5.2+dfsg/debian/patches/CVE-2023-3301.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2023-3301.patch 2023-08-22 13:42:52.000000000 +0200 @@ -0,0 +1,59 @@ +From aab37b2002811f112d5c26337473486d7d585881 Mon Sep 17 00:00:00 2001 +From: Ani Sinha <anisi...@redhat.com> +Date: Mon, 19 Jun 2023 12:22:09 +0530 +Subject: [PATCH] vhost-vdpa: do not cleanup the vdpa/vhost-net structures if + peer nic is present + +When a peer nic is still attached to the vdpa backend, it is too early to free +up the vhost-net and vdpa structures. If these structures are freed here, then +QEMU crashes when the guest is being shut down. The following call chain +would result in an assertion failure since the pointer returned from +vhost_vdpa_get_vhost_net() would be NULL: + +do_vm_stop() -> vm_state_notify() -> virtio_set_status() -> +virtio_net_vhost_status() -> get_vhost_net(). + +Therefore, we defer freeing up the structures until at guest shutdown +time when qemu_cleanup() calls net_cleanup() which then calls +qemu_del_net_client() which would eventually call vhost_vdpa_cleanup() +again to free up the structures. This time, the loop in net_cleanup() +ensures that vhost_vdpa_cleanup() will be called one last time when +all the peer nics are detached and freed. + +All unit tests pass with this change. + +CC: imamm...@redhat.com +CC: jus...@redhat.com +CC: m...@redhat.com +Fixes: CVE-2023-3301 +Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2128929 +Signed-off-by: Ani Sinha <anisi...@redhat.com> +Message-Id: <20230619065209.442185-1-anisi...@redhat.com> +Reviewed-by: Michael S. Tsirkin <m...@redhat.com> +Signed-off-by: Michael S. Tsirkin <m...@redhat.com> +(cherry picked from commit a0d7215e339b61c7d7a7b3fcf754954d80d93eb8) +Signed-off-by: Michael Tokarev <m...@tls.msk.ru> +(Mjt: context change for stable-8.0) +--- + net/vhost-vdpa.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + + +--- qemu-5.2+dfsg.orig/net/vhost-vdpa.c ++++ qemu-5.2+dfsg/net/vhost-vdpa.c +@@ -140,6 +140,15 @@ static void vhost_vdpa_cleanup(NetClient + { + VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc); + ++ /* ++ * If a peer NIC is attached, do not cleanup anything. ++ * Cleanup will happen as a part of qemu_cleanup() -> net_cleanup() ++ * when the guest is shutting down. ++ */ ++ if (nc->peer && nc->peer->info->type == NET_CLIENT_DRIVER_NIC) { ++ return; ++ } ++ + if (s->vhost_net) { + vhost_net_cleanup(s->vhost_net); + g_free(s->vhost_net); diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2023-3354.patch qemu-5.2+dfsg/debian/patches/CVE-2023-3354.patch --- qemu-5.2+dfsg/debian/patches/CVE-2023-3354.patch 1970-01-01 01:00:00.000000000 +0100 +++ qemu-5.2+dfsg/debian/patches/CVE-2023-3354.patch 2023-08-21 18:12:52.000000000 +0200 @@ -0,0 +1,79 @@ +From 5300472ec0990c61742d89b5eea1c1e6941f6d62 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berra...@redhat.com> +Date: Tue, 20 Jun 2023 09:45:34 +0100 +Subject: [PATCH] io: remove io watch if TLS channel is closed during handshake +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The TLS handshake make take some time to complete, during which time an +I/O watch might be registered with the main loop. If the owner of the +I/O channel invokes qio_channel_close() while the handshake is waiting +to continue the I/O watch must be removed. Failing to remove it will +later trigger the completion callback which the owner is not expecting +to receive. In the case of the VNC server, this results in a SEGV as +vnc_disconnect_start() tries to shutdown a client connection that is +already gone / NULL. + +CVE-2023-3354 +Reported-by: jiangyegen <jiangye...@huawei.com> +Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> +(cherry picked from commit 10be627d2b5ec2d6b3dce045144aa739eef678b4) +Signed-off-by: Michael Tokarev <m...@tls.msk.ru> +--- + include/io/channel-tls.h | 1 + + io/channel-tls.c | 18 ++++++++++++------ + 2 files changed, 13 insertions(+), 6 deletions(-) + + +--- qemu-5.2+dfsg.orig/include/io/channel-tls.h ++++ qemu-5.2+dfsg/include/io/channel-tls.h +@@ -48,6 +48,7 @@ struct QIOChannelTLS { + QIOChannel *master; + QCryptoTLSSession *session; + QIOChannelShutdown shutdown; ++ guint hs_ioc_tag; + }; + + /** +--- qemu-5.2+dfsg.orig/io/channel-tls.c ++++ qemu-5.2+dfsg/io/channel-tls.c +@@ -194,12 +194,13 @@ static void qio_channel_tls_handshake_ta + } + + trace_qio_channel_tls_handshake_pending(ioc, status); +- qio_channel_add_watch_full(ioc->master, +- condition, +- qio_channel_tls_handshake_io, +- data, +- NULL, +- context); ++ ioc->hs_ioc_tag = ++ qio_channel_add_watch_full(ioc->master, ++ condition, ++ qio_channel_tls_handshake_io, ++ data, ++ NULL, ++ context); + } + } + +@@ -214,6 +215,7 @@ static gboolean qio_channel_tls_handshak + QIOChannelTLS *tioc = QIO_CHANNEL_TLS( + qio_task_get_source(task)); + ++ tioc->hs_ioc_tag = 0; + g_free(data); + qio_channel_tls_handshake_task(tioc, task, context); + +@@ -371,6 +373,10 @@ static int qio_channel_tls_close(QIOChan + { + QIOChannelTLS *tioc = QIO_CHANNEL_TLS(ioc); + ++ if (tioc->hs_ioc_tag) { ++ g_clear_handle_id(&tioc->hs_ioc_tag, g_source_remove); ++ } ++ + return qio_channel_close(tioc->master, errp); + } + diff -Nru qemu-5.2+dfsg/debian/patches/series qemu-5.2+dfsg/debian/patches/series --- qemu-5.2+dfsg/debian/patches/series 2022-05-04 17:01:31.000000000 +0200 +++ qemu-5.2+dfsg/debian/patches/series 2023-09-04 16:11:35.000000000 +0200 @@ -63,3 +63,14 @@ display-qxl-render-fix-race-condition-in-qxl_cursor-CVE-2021-4207.patch virtiofsd-drop-membership-of-all-supplementary-group-CVE-2022-0358.patch vhost-vsock-detach-the-virqueue-element-on-error-CVE-2022-26354.patch +CVE-2020-14394.patch +CVE-2021-20196.patch +CVE-2021-20203.patch +CVE-2021-3507.patch +CVE-2021-3930.patch +CVE-2022-0216.patch +CVE-2023-0330.patch +CVE-2023-1544.patch +CVE-2023-3180.patch +CVE-2023-3301.patch +CVE-2023-3354.patch