--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: bullseye-pu: package qemu/1:5.2+dfsg-11+deb11u3
- From: Moritz Muehlenhoff <jmm@debian.org>
- Date: Tue, 19 Sep 2023 23:11:55 +0200
- Message-id: <169515791594.165755.16525145975949998091.reportbug@hullmann.westfalen.local>
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: qemu@packages.debian.org, mjt@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 <jmm@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 <thuth@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-thuth@redhat.com>
+Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com>
+Acked-by: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Thomas Huth <thuth@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?= <philmd@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?= <philmd@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 <pjp@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 <pgn@zju.edu.cn>
+Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
+Signed-off-by: Jason Wang <jasowang@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?= <philmd@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-stable@nongnu.org
+Cc: Hervé Poussineau <hpoussin@reactos.org>
+Fixes: baca51faff0 ("floppy driver: disk geometry auto detect")
+Reported-by: Alexander Bulekov <alxndr@bu.edu>
+Resolves: https://gitlab.com/qemu-project/qemu/-/issues/339
+Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
+Message-Id: <20211118115733.4038610-2-philmd@redhat.com>
+Reviewed-by: Hanna Reitz <hreitz@redhat.com>
+Signed-off-by: Kevin Wolf <kwolf@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 <mcascell@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-stable@nongnu.org
+Reported-by: Alexander Bulekov <alxndr@bu.edu>
+Fixes: a8f4bbe2900 ("scsi-disk: store valid mode pages in a table")
+Fixes: #546
+Reported-by: Qiuhao Li <Qiuhao.Li@outlook.com>
+Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@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 <mcascell@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 <mcascell@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 <thuth@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-thuth@redhat.com>
+Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
+Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
+Signed-off-by: Thomas Huth <thuth@redhat.com>
+(cherry picked from commit b987718bbb1d0eabf95499b976212dd5f0120d75)
+Signed-off-by: Michael Tokarev <mjt@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.ml@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 <wxhusst@gmail.com>
+Signed-off-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
+Message-Id: <20220403095234.2210-1-yuval.shaia.ml@gmail.com>
+Signed-off-by: Laurent Vivier <laurent@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 <pizhenwei@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.gonglei@huawei.com>
+Cc: Mauro Matteo Cascella <mcascell@redhat.com>
+Cc: Yiming Tao <taoym@zju.edu.cn>
+Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
+Message-Id: <20230803024314.29962-2-pizhenwei@bytedance.com>
+Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+(cherry picked from commit 9d38a8434721a6479fe03fb5afb150ca793d3980)
+Signed-off-by: Michael Tokarev <mjt@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 <anisinha@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: imammedo@redhat.com
+CC: jusual@redhat.com
+CC: mst@redhat.com
+Fixes: CVE-2023-3301
+Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2128929
+Signed-off-by: Ani Sinha <anisinha@redhat.com>
+Message-Id: <20230619065209.442185-1-anisinha@redhat.com>
+Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+(cherry picked from commit a0d7215e339b61c7d7a7b3fcf754954d80d93eb8)
+Signed-off-by: Michael Tokarev <mjt@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?= <berrange@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 <jiangyegen@huawei.com>
+Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
+(cherry picked from commit 10be627d2b5ec2d6b3dce045144aa739eef678b4)
+Signed-off-by: Michael Tokarev <mjt@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
--- End Message ---