qemu - Debian Package Tracker

general

source: qemu (main)
version: 1:11.0.0+ds-1
maintainer: Debian QEMU Team (archive) (DMD)
uploaders: Michael Tokarev [DMD]
arch: all
std-ver: 4.7.2
VCS: Git (Browse, QA)

versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]

[pool directory]

o-o-stable: 1:5.2+dfsg-11+deb11u3
o-o-sec: 1:5.2+dfsg-11+deb11u5
oldstable: 1:7.2+dfsg-7+deb12u18
old-sec: 1:7.2+dfsg-7+deb12u15
old-bpo: 1:10.0.2+ds-2+deb13u1~bpo12+1
stable: 1:10.0.8+ds-0+deb13u1
stable-sec: 1:10.0.2+ds-2+deb13u1
testing: 1:10.2.2+ds-1
unstable: 1:11.0.0+ds-1

versioned links

1:5.2+dfsg-11+deb11u3: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:5.2+dfsg-11+deb11u5: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:7.2+dfsg-7+deb12u15: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:7.2+dfsg-7+deb12u18: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:10.0.2+ds-2+deb13u1~bpo12+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:10.0.2+ds-2+deb13u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:10.0.8+ds-0+deb13u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:10.2.2+ds-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:11.0.0+ds-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

qemu-block-extra
qemu-guest-agent (1 bugs: 0, 0, 1, 0)
qemu-system (6 bugs: 0, 2, 4, 0)
qemu-system-arm (3 bugs: 0, 1, 2, 0)
qemu-system-common (5 bugs: 0, 0, 5, 0)
qemu-system-data (1 bugs: 0, 0, 1, 0)
qemu-system-gui (2 bugs: 0, 2, 0, 0)
qemu-system-mips
qemu-system-misc
qemu-system-modules-opengl
qemu-system-modules-spice
qemu-system-ppc (3 bugs: 0, 3, 0, 0)
qemu-system-riscv (1 bugs: 0, 1, 0, 0)
qemu-system-s390x
qemu-system-sparc
qemu-system-x86 (19 bugs: 0, 14, 5, 0)
qemu-system-xen
qemu-user (3 bugs: 0, 2, 1, 0)
qemu-user-binfmt (1 bugs: 0, 1, 0, 0)
qemu-utils (1 bugs: 0, 1, 0, 0)

action needed

19 security issues in trixie high

There are 19 open security issues in trixie.

2 important issues:

CVE-2026-5744:
CVE-2026-5761:

17 issues left for the package maintainer to handle:

CVE-2021-3735: (postponed; to be fixed through a stable update) A deadlock issue was found in the AHCI controller device of QEMU. It occurs on a software reset (ahci_reset_port) while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.
CVE-2022-3872: (postponed; to be fixed through a stable update) An off-by-one read/write issue was found in the SDHCI device of QEMU. It occurs when reading/writing the Buffer Data Port Register in sdhci_read_dataport and sdhci_write_dataport, respectively, if data_count == block_size. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.
CVE-2023-1386: (postponed; to be fixed through a stable update) A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. When a local user in the guest writes an executable file with SUID or SGID, none of these privileged bits are correctly dropped. As a result, in rare circumstances, this flaw could be used by malicious users in the guest to elevate their privileges within the guest and help a host local user to elevate privileges on the host.
CVE-2024-6519: (needs triaging) A use-after-free vulnerability was found in the QEMU LSI53C895A SCSI Host Bus Adapter emulation. This issue can lead to a crash or VM escape.
CVE-2024-8354: (needs triaging) A flaw was found in QEMU. An assertion failure was present in the usb_ep_get() function in hw/net/core.c when trying to get the USB endpoint from a USB device. This flaw may allow a malicious unprivileged guest user to crash the QEMU process on the host and cause a denial of service condition.
CVE-2024-8612: (needs triaging) A flaw was found in QEMU, in the virtio-scsi, virtio-blk, and virtio-crypto devices. The size for virtqueue_push as set in virtio_scsi_complete_req / virtio_blk_req_complete / virito_crypto_req_complete could be larger than the true size of the data which has been sent to guest. Once virtqueue_push() finally calls dma_memory_unmap to ummap the in_iov, it may call the address_space_write function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.
CVE-2026-2243: (needs triaging) A flaw was found in QEMU. A specially crafted VMDK image could trigger an out-of-bounds read vulnerability, potentially leading to a 12-byte leak of sensitive information or a denial of service condition (DoS).
CVE-2026-3195: (needs triaging)
CVE-2026-3196: (needs triaging)
CVE-2026-3842: (needs triaging)
CVE-2026-3890: (needs triaging)
CVE-2026-5763: (needs triaging)
CVE-2019-12067: (postponed; to be fixed through a stable update) The ahci_commit_buf function in ide/ahci.c in QEMU allows attackers to cause a denial of service (NULL dereference) when the command header 'ad->cur_cmd' is null.
CVE-2020-25741: (postponed; to be fixed through a stable update) fdctrl_write_data in hw/block/fdc.c in QEMU 5.0.0 has a NULL pointer dereference via a NULL block pointer for the current drive.
CVE-2020-25742: (postponed; to be fixed through a stable update) pci_change_irq_level in hw/pci/pci.c in QEMU before 5.1.1 has a NULL pointer dereference because pci_get_bus() might not return a valid pointer.
CVE-2020-25743: (postponed; to be fixed through a stable update) hw/ide/pci.c in QEMU before 5.1.1 can trigger a NULL pointer dereference because it lacks a pointer check before an ide_cancel_dma_sync call.
CVE-2020-35503: (postponed; to be fixed through a stable update) A NULL pointer dereference flaw was found in the megasas-gen2 SCSI host bus adapter emulation of QEMU in versions before and including 6.0. This issue occurs in the megasas_command_cancelled() callback function while dropping a SCSI request. This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.

You can find information about how to handle these issues in the security team's documentation.

Created: 2023-06-11 Last update: 2026-04-23 17:30

10 security issues in sid high

There are 10 open security issues in sid.

10 important issues:

CVE-2021-3735: A deadlock issue was found in the AHCI controller device of QEMU. It occurs on a software reset (ahci_reset_port) while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.
CVE-2022-3872: An off-by-one read/write issue was found in the SDHCI device of QEMU. It occurs when reading/writing the Buffer Data Port Register in sdhci_read_dataport and sdhci_write_dataport, respectively, if data_count == block_size. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.
CVE-2023-1386: A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. When a local user in the guest writes an executable file with SUID or SGID, none of these privileged bits are correctly dropped. As a result, in rare circumstances, this flaw could be used by malicious users in the guest to elevate their privileges within the guest and help a host local user to elevate privileges on the host.
CVE-2024-6519: A use-after-free vulnerability was found in the QEMU LSI53C895A SCSI Host Bus Adapter emulation. This issue can lead to a crash or VM escape.
CVE-2024-8612: A flaw was found in QEMU, in the virtio-scsi, virtio-blk, and virtio-crypto devices. The size for virtqueue_push as set in virtio_scsi_complete_req / virtio_blk_req_complete / virito_crypto_req_complete could be larger than the true size of the data which has been sent to guest. Once virtqueue_push() finally calls dma_memory_unmap to ummap the in_iov, it may call the address_space_write function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.
CVE-2019-12067: The ahci_commit_buf function in ide/ahci.c in QEMU allows attackers to cause a denial of service (NULL dereference) when the command header 'ad->cur_cmd' is null.
CVE-2020-25741: fdctrl_write_data in hw/block/fdc.c in QEMU 5.0.0 has a NULL pointer dereference via a NULL block pointer for the current drive.
CVE-2020-25742: pci_change_irq_level in hw/pci/pci.c in QEMU before 5.1.1 has a NULL pointer dereference because pci_get_bus() might not return a valid pointer.
CVE-2020-25743: hw/ide/pci.c in QEMU before 5.1.1 can trigger a NULL pointer dereference because it lacks a pointer check before an ide_cancel_dma_sync call.
CVE-2020-35503: A NULL pointer dereference flaw was found in the megasas-gen2 SCSI host bus adapter emulation of QEMU in versions before and including 6.0. This issue occurs in the megasas_command_cancelled() callback function while dropping a SCSI request. This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.

Created: 2022-07-04 Last update: 2026-04-23 17:30

14 security issues in forky high

There are 14 open security issues in forky.

14 important issues:

CVE-2021-3735: A deadlock issue was found in the AHCI controller device of QEMU. It occurs on a software reset (ahci_reset_port) while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.
CVE-2022-3872: An off-by-one read/write issue was found in the SDHCI device of QEMU. It occurs when reading/writing the Buffer Data Port Register in sdhci_read_dataport and sdhci_write_dataport, respectively, if data_count == block_size. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.
CVE-2023-1386: A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. When a local user in the guest writes an executable file with SUID or SGID, none of these privileged bits are correctly dropped. As a result, in rare circumstances, this flaw could be used by malicious users in the guest to elevate their privileges within the guest and help a host local user to elevate privileges on the host.
CVE-2024-6519: A use-after-free vulnerability was found in the QEMU LSI53C895A SCSI Host Bus Adapter emulation. This issue can lead to a crash or VM escape.
CVE-2024-8612: A flaw was found in QEMU, in the virtio-scsi, virtio-blk, and virtio-crypto devices. The size for virtqueue_push as set in virtio_scsi_complete_req / virtio_blk_req_complete / virito_crypto_req_complete could be larger than the true size of the data which has been sent to guest. Once virtqueue_push() finally calls dma_memory_unmap to ummap the in_iov, it may call the address_space_write function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.
CVE-2026-3890:
CVE-2026-5744:
CVE-2026-5761:
CVE-2026-5763:
CVE-2019-12067: The ahci_commit_buf function in ide/ahci.c in QEMU allows attackers to cause a denial of service (NULL dereference) when the command header 'ad->cur_cmd' is null.
CVE-2020-25741: fdctrl_write_data in hw/block/fdc.c in QEMU 5.0.0 has a NULL pointer dereference via a NULL block pointer for the current drive.
CVE-2020-25742: pci_change_irq_level in hw/pci/pci.c in QEMU before 5.1.1 has a NULL pointer dereference because pci_get_bus() might not return a valid pointer.
CVE-2020-25743: hw/ide/pci.c in QEMU before 5.1.1 can trigger a NULL pointer dereference because it lacks a pointer check before an ide_cancel_dma_sync call.
CVE-2020-35503: A NULL pointer dereference flaw was found in the megasas-gen2 SCSI host bus adapter emulation of QEMU in versions before and including 6.0. This issue occurs in the megasas_command_cancelled() callback function while dropping a SCSI request. This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.

Created: 2025-08-09 Last update: 2026-04-23 17:30

29 security issues in bullseye high

There are 29 open security issues in bullseye.

2 important issues:

CVE-2026-3890:
CVE-2026-5763:

16 issues postponed or untriaged:

CVE-2021-3735: (postponed; to be fixed through a stable update) A deadlock issue was found in the AHCI controller device of QEMU. It occurs on a software reset (ahci_reset_port) while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.
CVE-2022-3872: (postponed; to be fixed through a stable update) An off-by-one read/write issue was found in the SDHCI device of QEMU. It occurs when reading/writing the Buffer Data Port Register in sdhci_read_dataport and sdhci_write_dataport, respectively, if data_count == block_size. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.
CVE-2023-1386: (postponed; to be fixed through a stable update) A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. When a local user in the guest writes an executable file with SUID or SGID, none of these privileged bits are correctly dropped. As a result, in rare circumstances, this flaw could be used by malicious users in the guest to elevate their privileges within the guest and help a host local user to elevate privileges on the host.
CVE-2024-6505: (postponed; to be fixed through a stable update) A flaw was found in the virtio-net device in QEMU. When enabling the RSS feature on the virtio-net network card, the indirections_table data within RSS becomes controllable. Setting excessively large values may cause an index out-of-bounds issue, potentially resulting in heap overflow access. This flaw allows a privileged user in the guest to crash the QEMU process on the host.
CVE-2024-6519: (postponed; to be fixed through a stable update) A use-after-free vulnerability was found in the QEMU LSI53C895A SCSI Host Bus Adapter emulation. This issue can lead to a crash or VM escape.
CVE-2024-7730: (postponed; to be fixed through a stable update) A heap buffer overflow was found in the virtio-snd device in QEMU. When reading input audio in the virtio-snd input callback, virtio_snd_pcm_in_cb, the function did not check whether the iov can fit the data buffer. This issue can trigger an out-of-bounds write if the size of the virtio queue element is equal to virtio_snd_pcm_status, which makes the available space for audio data zero.
CVE-2024-8354: (postponed; to be fixed through a stable update) A flaw was found in QEMU. An assertion failure was present in the usb_ep_get() function in hw/net/core.c when trying to get the USB endpoint from a USB device. This flaw may allow a malicious unprivileged guest user to crash the QEMU process on the host and cause a denial of service condition.
CVE-2024-8612: (postponed; to be fixed through a stable update) A flaw was found in QEMU, in the virtio-scsi, virtio-blk, and virtio-crypto devices. The size for virtqueue_push as set in virtio_scsi_complete_req / virtio_blk_req_complete / virito_crypto_req_complete could be larger than the true size of the data which has been sent to guest. Once virtqueue_push() finally calls dma_memory_unmap to ummap the in_iov, it may call the address_space_write function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.
CVE-2026-2243: (postponed; to be fixed through a stable update) A flaw was found in QEMU. A specially crafted VMDK image could trigger an out-of-bounds read vulnerability, potentially leading to a 12-byte leak of sensitive information or a denial of service condition (DoS).
CVE-2019-12067: (postponed; to be fixed through a stable update) The ahci_commit_buf function in ide/ahci.c in QEMU allows attackers to cause a denial of service (NULL dereference) when the command header 'ad->cur_cmd' is null.
CVE-2020-25741: (postponed; to be fixed through a stable update) fdctrl_write_data in hw/block/fdc.c in QEMU 5.0.0 has a NULL pointer dereference via a NULL block pointer for the current drive.
CVE-2020-25742: (postponed; to be fixed through a stable update) pci_change_irq_level in hw/pci/pci.c in QEMU before 5.1.1 has a NULL pointer dereference because pci_get_bus() might not return a valid pointer.
CVE-2020-25743: (postponed; to be fixed through a stable update) hw/ide/pci.c in QEMU before 5.1.1 can trigger a NULL pointer dereference because it lacks a pointer check before an ide_cancel_dma_sync call.
CVE-2020-35503: (postponed; to be fixed through a stable update) A NULL pointer dereference flaw was found in the megasas-gen2 SCSI host bus adapter emulation of QEMU in versions before and including 6.0. This issue occurs in the megasas_command_cancelled() callback function while dropping a SCSI request. This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
CVE-2021-20255: (postponed; to be fixed through a stable update) A stack overflow via an infinite recursion vulnerability was found in the eepro100 i8255x device emulator of QEMU. This issue occurs while processing controller commands due to a DMA reentry issue. This flaw allows a guest user or process to consume CPU cycles or crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
CVE-2025-11234: (needs triaging) A flaw was found in QEMU. If the QIOChannelWebsock object is freed while it is waiting to complete a handshake, a GSource is leaked. This can lead to the callback firing later on and triggering a use-after-free in the use of the channel. This can be abused by a malicious client with network access to the VNC WebSocket port to cause a denial of service during the WebSocket handshake prior to the VNC client authentication.

11 ignored issues:

CVE-2021-3611: A stack overflow vulnerability was found in the Intel HD Audio device (intel-hda) of QEMU. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability. This flaw affects QEMU versions prior to 7.0.0.
CVE-2021-3750: A DMA reentrancy issue was found in the USB EHCI controller emulation of QEMU. EHCI does not verify if the Buffer Pointer overlaps with its MMIO region when it transfers the USB packets. Crafted content may be written to the controller's registers and trigger undesirable actions (such as reset) while the device is still transferring packets. This can ultimately lead to a use-after-free issue. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition, or potentially execute arbitrary code within the context of the QEMU process on the host. This flaw affects QEMU versions before 7.0.0.
CVE-2021-3929: A DMA reentrancy issue was found in the NVM Express Controller (NVME) emulation in QEMU. This CVE is similar to CVE-2021-3750 and, just like it, when the reentrancy write triggers the reset function nvme_ctrl_reset(), data structs will be freed leading to a use-after-free issue. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host.
CVE-2022-4144: An out-of-bounds read flaw was found in the QXL display device emulation in QEMU. The qxl_phys2virt() function does not check the size of the structure pointed to by the guest physical address, potentially reading past the end of the bar space into adjacent pages. A malicious guest user could use this flaw to crash the QEMU process on the host causing a denial of service condition.
CVE-2023-2861: A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. The 9pfs server did not prohibit opening special files on the host side, potentially allowing a malicious client to escape from the exported 9p tree by creating and opening a device file in the shared folder.
CVE-2024-3446: A double free vulnerability was found in QEMU virtio devices (virtio-gpu, virtio-serial-bus, virtio-crypto), where the mem_reentrancy_guard flag insufficiently protects against DMA reentrancy issues. This issue could allow a malicious privileged guest user to crash the QEMU process on the host, resulting in a denial of service or allow arbitrary code execution within the context of the QEMU process on the host.
CVE-2024-4467: A flaw was found in the QEMU disk image utility (qemu-img) 'info' command. A specially crafted image file containing a `json:{}` value describing block devices in QMP could cause the qemu-img process on the host to consume large amounts of memory or CPU time, leading to denial of service or read/write to an existing external file.
CVE-2020-15469: In QEMU 4.2.0, a MemoryRegionOps object may lack read/write callback methods, leading to a NULL pointer dereference.
CVE-2020-35504: A NULL pointer dereference flaw was found in the SCSI emulation support of QEMU in versions before 6.0.0. This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
CVE-2020-35505: A NULL pointer dereference flaw was found in the am53c974 SCSI host bus adapter emulation of QEMU in versions before 6.0.0. This issue occurs while handling the 'Information Transfer' command. This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
CVE-2020-35506: A use-after-free vulnerability was found in the am53c974 SCSI host bus adapter emulation of QEMU in versions before 6.0.0 during the handling of the 'Information Transfer' command (CMD_TI). This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service or potential code execution with the privileges of the QEMU process.

Created: 2026-04-23 Last update: 2026-04-23 17:30

Does not build reproducibly during testing normal

A package building reproducibly enables third parties to verify that the source matches the distributed binaries. It has been identified that this source package produced different results, failed to build or had other issues in a test environment. Please read about how to improve the situation!

Created: 2026-04-06 Last update: 2026-04-24 09:00

22989 new commits since last upload, is it time to release? normal

vcswatch reports that this package seems to have new commits in its VCS but has not yet updated debian/changelog. You should consider updating the Debian changelog and uploading this new version into the archive.

Here are the relevant commit logs:

commit 25649b53f52c41a9d8f09b86bd920ccf6c6be6da
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:48:37 2026 +0300

    d/changelog: wrap long lines in previous entry

commit 0e2fd246dd3b5a0acde5883d7d079b2781a89e7d
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:38:52 2026 +0300

    update changelog; upload version 11.0.0+ds-1 to unstable

commit 81483a57a95dc7c3b3bbe142eb8cfec26abe3db2
Merge: 4de3bcba7 e4bc5161e
Author: Michael Tokarev <mjt@debian.org>
Date:   Wed Apr 22 21:31:56 2026 +0300

    Merge branch 'fix-qemu-guest-agent-start' into 'master'
    
    d/qemu-guest-agent.postinst: trigger udev rule to start the service
    
    See merge request qemu-team/qemu!52

commit 4de3bcba749f736218172db3cc45d13e4c2976be
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:19:16 2026 +0300

    d/gbp.conf: upstream-11.0

commit 148778396ea7bc8ab8b361301f8cedd739da6d94
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:14:56 2026 +0300

    hw-q35-fix-VGA-text-console-with-SMM-disabled.patch: replace 1095935.patch

commit 0982e525454bc01f88746351e31e3577441daf08
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Sat Apr 11 13:03:00 2026 +0300

    d/rules: pass --cpu= explicitly for (some) 32bit architectures

commit 00c4612e9a8a857ce89778717b2937dca3ea67e9
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Mar 25 11:21:42 2026 +0300

    d/control: remove 32bit architectures from libseccomp build-dependency, add comment

commit 7efa6f6ac429a941a16f745ea7372b31264bdcac
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Mar 25 12:47:14 2026 +0300

    d/rules: drop another mention of 32bit host arch

commit b8c3716a06b1de25638716857824e49b30d2227b
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 22:46:24 2026 +0300

    d/control: remove 32bit host, system-arch and user-arch are always 64bits
    
    Stop providing qemu-system* and qemu-user* on 32bit architectures.
    This might require providing "transitional-to-nothing" packages.

commit e1573eb4609087b44979d4ba25ca8a885daffb2b
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 22:22:43 2026 +0300

    seabios-hppa-stdbool.diff: fix ftbfs

commit 5d5d17531b6faecc56ca76d2453dc569af8898f2
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 13:13:55 2026 +0300

    d/rules,d/qemu-system-common.install: install accel-qtest.so
    
    now once there's just one accel-qtest.so, include it in qemu-system-common

commit 468700b5ee0095f5af0d23fabf14555fb42be952
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:09:55 2026 +0300

    d/control: add python3-qemu-qmp to qemu-system-common:Suggests

commit d485ab6d098b5ba784b6ab2faed2097fde60e3de
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 16:08:06 2026 +0300

    d/control: add python3-qemu-qmp build dependency

commit 4b33ce575b37ea6bde446611adf29ceba7fa5e62
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:08:09 2026 +0300

    d/control: add python3-pip build dependency

commit 22000c9aae92a250aadb0385867816330c954649
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:06:45 2026 +0300

    d/control.mk: checked-version := 11.0.0+ds

commit e13c9558275e86df2a795e82541cf57361411696
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 10:09:27 2026 +0300

    d/control*: remove qemu-system-microblazeel (now handled by qemu-system-microblaze)

commit 3ae9de5b24b54283af15259f03d158df925ca77b
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 10:07:18 2026 +0300

    d/patches: refresh

commit 28b5fdd1b768ff354c1238375cb30ff6a5e8b1ee
Merge: 1621b1728 90309c699
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:04:56 2026 +0300

    Update upstream source from tag 'upstream/11.0.0+ds'
    
    Update to upstream version '11.0.0+ds'
    with Debian dir 67c4373dc32ac96471c9d3d7bbd7f51d2079eba8

commit 1621b17281bb9857727b2ebaa687c9e7c868cac2
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Fri Apr 3 11:55:37 2026 +0300

    d/copyright: remove obsolete linuxboot.bin & multiboot.bin

commit 2977370f9441279e8d4b27d9676066a3e8bd202c
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 21:01:44 2026 +0300

    d/watch: 11.0.x

commit b790f1defcd4dbf99d207d26e660d9068ba4851c
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Apr 22 20:59:53 2026 +0300

    d/gbp.conf: 11.0

commit e4bc5161e304a6ecc740040dd2432e33dc6f0a5b
Author: Hector Cao <hector.cao@canonical.com>
Date:   Wed Apr 22 10:59:14 2026 +0200

    d/qemu-guest-agent.postinst: trigger udev rule to start the service

commit 97f92870f41e9b1d14c17861bff5f48f8d48e358
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Mar 25 12:14:42 2026 +0300

    d/rules: make --enable-tools to depend on qemu-utils being in build packages list or not

commit 7a57fb466038ba4a1b6c509c68d55858c5eb63b6
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Mar 25 12:13:49 2026 +0300

    d/control: libudev is only needed for system build on linux

commit 0d0dca0c2f83f11ef4c6aa52b0ae45d829f6c12e
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Wed Mar 25 11:23:00 2026 +0300

    d/control: rdma is only needed for system build on linux

commit 29afa9f4af1bcb1e83f264aa2ff9bc062cdbf925
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 12:35:32 2026 +0300

    d/patches,d/control: drop disable-pycotap.patch, build-depend on python3-pycotap instead

commit 07ef8b7f0189fc01edfff764d03e6dd4829f7cfe
Merge: cc1f4a1a4 4de9fd7cc
Author: Michael Tokarev <mjt@debian.org>
Date:   Wed Mar 25 12:39:12 2026 +0300

    Merge branch 'remove-deprecated-edk2-firmware' into 'master'
    
    d/control-in: remove dependency on deprecated edk2 arm
    
    See merge request qemu-team/qemu!51

commit 4de9fd7cce1a939df92e1ba548df6affb72621cc
Author: Hector Cao <hector.cao@canonical.com>
Date:   Wed Mar 25 10:39:12 2026 +0100

    d/control-in: remove dependency on deprecated edk2 arm

commit cc1f4a1a462434a030eaab04fafbd51a7e8881dd
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Fri Mar 20 12:54:41 2026 +0300

    d/changelog: mention closing of #1129349

commit 9311b2217325a408c9921eda8cfe96506ed428e3
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 23:33:37 2026 +0300

    update changelog; upload version 10.2.2+ds-1 to unstable

commit e8f039e6306cdae338ddae8e13a81d17a534f067
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 22:23:22 2026 +0300

    d/control.mk: checked-version := 10.2.2+ds

commit 1a677aae3176e3280d221bcc21aaa17f62fe0344
Merge: d8b3ae808 59b73867b
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 18:33:21 2026 +0300

    Update upstream source from tag 'upstream/10.2.2+ds'
    
    Update to upstream version '10.2.2+ds'
    with Debian dir cc6c28225d8743416f887257e9ae9e85bc56a316

commit 59b73867b3ea0629f3b75da2b9a32246fea8ac58
Merge: cc25a61ad f8ed81651
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Mar 19 18:32:56 2026 +0300

    New upstream version 10.2.2+ds

commit f8ed81651e61d9c2166df6121ce2af0f44f06b3e
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Tue Mar 17 11:33:17 2026 +0300

    Update version for 10.2.2 release
    
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 0103b23cb730dfdd561ad508ab0ce4a4f2ee37d8
Author: Fiona Ebner <f.ebner@proxmox.com>
Date:   Tue Mar 10 16:43:23 2026 +0100

    target/i386: add compat for migrating error code
    
    If cpu->env.has_error_code is true, backwards migration of a VM from
    a QEMU binary with commit 27535e9cca to a QEMU binary without commit
    27535e9cca will fail:
    
    > kvm: error while loading state for instance 0x0 of device 'cpu'
    
    In practice, wrongly setting the error code to 0 on the target is
    often unproblematic, so additionally checking error_code != 0 in
    cpu_errcode_needed() is not enough to mitigate the issue. Instead, add
    proper machine version compat handling.
    
    Cc: qemu-stable@nongnu.org
    Fixes: 27535e9cca ("target/i386: Add support for save/load of exception error code")
    Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
    Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
    Link: https://lore.kernel.org/r/20260310154348.495332-1-f.ebner@proxmox.com
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    (cherry picked from commit 1b80f1009dcaf19b4a82a63ab4e52833374e31cc)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 85af4e937016ed2f20122eb116597d1abb30c5c0
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Mar 9 13:20:35 2026 +0100

    hyperv/syndbg: check length returned by cpu_physical_memory_map()
    
    If cpu_physical_memory_map() returns a length shorter than the one
    that was passed into the function, writing the full out_len bytes
    causes an access beyond the memory allocated to the guest; or in
    the case of the MMIO bounce buffer, an out-of-bounds access in a
    heap-allocated object.
    
    Add a check similar to the one already in handle_send_msg(),
    and take the occasion to remove repeated computations of
    recv_byte_count + UDP_PKT_HEADER_SIZE and clarify that the
    code does not write past out_len bytes.
    
    Reported-by: Oleh Konko <https://github.com/1seal>
    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
    Fixes: CVE-2026-3842
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    (cherry picked from commit 4f28b87fdd24df2049626106b7c24d0180952115)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 3e7e7cf05a408edfb2f62167f59d763b21df7f30
Author: Hanna Czenczek <hreitz@redhat.com>
Date:   Mon Mar 9 16:08:32 2026 +0100

    fuse: Copy write buffer content before polling
    
    aio_poll() in I/O functions can lead to nested read_from_fuse_export()
    calls, overwriting the request buffer's content.  The only function
    affected by this is fuse_write(), which therefore must use a bounce
    buffer or corruption may occur.
    
    Note that in addition we do not know whether libfuse-internal structures
    can cope with this nesting, and even if we did, we probably cannot rely
    on it in the future.  This is the main reason why we want to remove
    libfuse from the I/O path.
    
    I do not have a good reproducer for this other than:
    
    $ dd if=/dev/urandom of=image bs=1M count=4096
    $ dd if=/dev/zero of=copy bs=1M count=4096
    $ touch fuse-export
    $ qemu-storage-daemon \
        --blockdev file,node-name=file,filename=copy \
        --export \
        fuse,id=exp,node-name=file,mountpoint=fuse-export,writable=true \
        &
    
    Other shell:
    $ qemu-img convert -p -n -f raw -O raw -t none image fuse-export
    $ killall -SIGINT qemu-storage-daemon
    $ qemu-img compare image copy
    Content mismatch at offset 0!
    
    (The -t none in qemu-img convert is important.)
    
    I tried reproducing this with throttle and small aio_write requests from
    another qemu-io instance, but for some reason all requests are perfectly
    serialized then.
    
    I think in theory we should get parallel writes only if we set
    fi->parallel_direct_writes in fuse_open().  In fact, I can confirm that
    if we do that, that throttle-based reproducer works (i.e. does get
    parallel (nested) write requests).  I have no idea why we still get
    parallel requests with qemu-img convert anyway.
    
    Also, a later patch in this series will set fi->parallel_direct_writes
    and note that it makes basically no difference when running fio on the
    current libfuse-based version of our code.  It does make a difference
    without libfuse.  So something quite fishy is going on.
    
    I will try to investigate further what the root cause is, but I think
    for now let's assume that calling blk_pwrite() can invalidate the buffer
    contents through nested polling.
    
    Cc: qemu-stable@nongnu.org
    Reviewed-by: Kevin Wolf <kwolf@redhat.com>
    Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
    Message-ID: <20260309150856.26800-2-hreitz@redhat.com>
    Reviewed-by: Kevin Wolf <kwolf@redhat.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    (cherry picked from commit a3fcbca0ef643a8aecf354bdeb08b1d81e5b33e7)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 8b3b97dae50621b281728257ee01d78e811a7476
Author: rail5 <andrew@rail5.org>
Date:   Fri Mar 6 15:33:36 2026 +0800

    target/loongarch: Preserve PTE permission bits in LDPTE
    
    The LDPTE helper loads a page table entry (or huge page entry) from guest
    memory and currently applies the PALEN mask to the whole 64-bit value.
    
    That mask is intended to constrain the physical address bits, but masking
    the full entry also clears upper permission bits in the PTE, including NX
    (bit 62). As a result, LoongArch TCG can incorrectly allow instruction
    fetches from NX mappings when translation is driven through software
    page-walk.
    
    Fix this by masking only the PPN/address field with PALEN while preserving
    permission bits, and by clearing any non-architectural (software) bits
    using a hardware PTE mask. LDDIR is unchanged since it returns the base
    address of the next page table level.
    
    Reported at: https://gitlab.com/qemu-project/qemu/-/issues/3319
    
    -Fixes: 56599a705f2 ("target/loongarch: Introduce loongarch_palen_mask()")
    Fixes: d2cba6f7cea9 ("target/loongarch: Add other core instructions support")
    Cc: qemu-stable@nongnu.org
    Signed-off-by: rail5 (Andrew S. Rightenburg) <andrew@rail5.org>
    Reviewed-by: Bibo Mao <maobibo@loongson.cn>
    Reviewed-by: Song Gao <gaosong@loongson.cn>
    Signed-off-by: Song Gao <gaosong@loongson.cn>
    (cherry picked from commit 2d877bc02a3b94998cbdd784d194c173d308a98a)
    (Mjt: backport to 10.2.x which lacks v10.2.0-1568-g56599a705f
     "target/loongarch: Introduce loongarch_palen_mask()")
    (fixing the Fixes: tag)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 477d1f3c5952d6dcb6c3df14e40fb0e5ab2a822d
Author: rail5 <andrew@rail5.org>
Date:   Fri Mar 6 15:33:37 2026 +0800

    target/loongarch: Avoid recursive PNX exception on CSR_BADI fetch
    
    loongarch_cpu_do_interrupt() updates CSR_BADI by fetching the faulting
    instruction with cpu_ldl_code_mmu().
    
    For a PNX exception (instruction fetch prohibited by NX), fetching the
    instruction at env->pc will fault with PNX again. This can lead to an
    infinite exception loop.
    
    Treat PNX like other instruction-fetch exceptions (PIF/ADEF) and do not
    update CSR_BADI for it.
    
    -Fixes: 410dfbf620a ("target/loongarch: Move TCG specified functions to tcg_cpu.c")
    Fixes: f757a2cd6948 ("target/loongarch: Add LoongArch interrupt and exception handler")
    Cc: qemu-stable@nongnu.org
    Signed-off-by: rail5 (Andrew S. Rightenburg) <andrew@rail5.org>
    Reviewed-by: Bibo Mao <maobibo@loongson.cn>
    Reviewed-by: Song Gao <gaosong@loongson.cn>
    Signed-off-by: Song Gao <gaosong@loongson.cn>
    (cherry picked from commit db2325f79481fab87211e5a287580d753f582cb8)
    (fixing the Fixes: tag)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit f07f64c3d847d19940b515a9756c4e1ecedb636c
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Sat Mar 7 15:50:46 2026 +0000

    hw: Make qdev_get_printable_name() consistently return freeable string
    
    The current implementation of qdev_get_printable_name() sometimes
    returns a string that must not be freed (vdev->id or the fixed
    fallback string "<unknown device>" and sometimes returns a string
    that must be freed (the return value of qdev_get_dev_path()). This
    forces callers to leak the string in the "must be freed" case.
    
    Make the function consistent that it always returns a string that
    the caller must free, and make the three callsites free it.
    
    This fixes leaks like this that show up when running "make check"
    with the address sanitizer enabled:
    
    Direct leak of 13 byte(s) in 1 object(s) allocated from:
        #0 0x5561de21f293 in malloc (/home/pm215/qemu/build/san/qemu-system-i386+0x1a2d293) (BuildId: 6d6fad7130fd5c8dbbc03401df554f68b8034936)
        #1 0x767ad7a82ac9 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62ac9) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
        #2 0x5561deaf34f2 in pcibus_get_dev_path /home/pm215/qemu/build/san/../../hw/pci/pci.c:2792:12
        #3 0x5561df9d8830 in qdev_get_printable_name /home/pm215/qemu/build/san/../../hw/core/qdev.c:431:24
        #4 0x5561deebdca2 in virtio_init_region_cache /home/pm215/qemu/build/san/../../hw/virtio/virtio.c:298:17
        #5 0x5561df05f842 in memory_region_write_accessor /home/pm215/qemu/build/san/../../system/memory.c:491:5
        #6 0x5561df05ed1b in access_with_adjusted_size /home/pm215/qemu/build/san/../../system/memory.c:567:18
        #7 0x5561df05e3fa in memory_region_dispatch_write /home/pm215/qemu/build/san/../../system/memory.c
        #8 0x5561df0aa805 in address_space_stm_internal /home/pm215/qemu/build/san/../../system/memory_ldst.c.inc:85:13
        #9 0x5561df0bcad3 in qtest_process_command /home/pm215/qemu/build/san/../../system/qtest.c:480:13
    
    Cc: qemu-stable@nongnu.org
    Fixes: e209d4d7a31b9 ("virtio: improve virtqueue mapping error messages")
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Message-ID: <20260307155046.3940197-3-peter.maydell@linaro.org>
    Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    (cherry picked from commit 1e3e1d51e20e8b38efa089bf54b5ee2cbbcca221)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit a69152d2571c69a27349ba31cd45fc2d15738950
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Fri Mar 6 15:40:16 2026 +0000

    hw/net/npcm_gmac: Catch accesses off the end of the register array
    
    In the npcm_gmac device, we create the iomem MemoryRegion with
    a size of 8KB, but NPCM_GMAC_NR_REGS is only 0x1060 / 4. This
    means there's a range of offsets that the guest can access
    that don't have gmac->regs[] entries. We weren't catching this,
    so the guest could get us to index off the end of the regs array.
    
    Catch and log these invalid accesses.
    
    Cc: qemu-stable@nongnu.org
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3316
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Message-ID: <20260306154016.2194091-1-peter.maydell@linaro.org>
    Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    (cherry picked from commit 550391c7134d295d73b2b0e7a1111a922b78c13c)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 6f6bdf376347475cc0f207ef142e5122fd36fb22
Author: Andreas Schwab <schwab@suse.de>
Date:   Tue Feb 10 10:20:39 2026 +0100

    linux-user: fix TIOCGSID ioctl
    
    TIOCGSID is IOC_R, not IOC_W.
    
    Signed-off-by: Andreas Schwab <schwab@suse.de>
    Reviewed-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    (cherry picked from commit 6a1221614fd9344a22cafea78e48d6ded95f317d)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 2481744d961121e311381b5781a8d35f628722f2
Author: Bingwu Zhang <xtex@astrafall.org>
Date:   Sat Feb 28 00:46:33 2026 +0800

    tests/tcg/multiarch/test-mmap: Check mmaps beyond reserved_va
    
    Unfixed mmap calls where start > reserved_va or the max guest addr
    should have a valid result.
    
    Signed-off-by: Bingwu Zhang <xtex@astrafall.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    (cherry picked from commit c865b6bce5d0c882b86fb7c3512174cdaf235017)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit ed18bbbc117bc993af97fa7109b36e62847f58e6
Author: Bingwu Zhang <xtex@astrafall.org>
Date:   Sat Feb 28 00:46:31 2026 +0800

    bsd-user: Deal with mmap where start > reserved_va
    
    Fixes: f12294b5bd21 ("bsd-user: Use page_find_range_empty for mmap_find_vma_reserved")
    Signed-off-by: Bingwu Zhang <xtex@astrafall.org>
    Reviewed-by: Helge Deller <deller@gmx.de>
    Reviewed-by: Warner Losh <imp@bsdimp.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    (cherry picked from commit e8e7d1f97785be2fd81fc520e0c7b9d228c10a56)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 82d83d29bd419a416d3aacf820e46a664030ec7e
Author: Bingwu Zhang <xtex@astrafall.org>
Date:   Sat Feb 28 00:46:30 2026 +0800

    linux-user: Deal with mmap where start > reserved_va
    
    Fixes: 4c13048e02d9 ("linux-user: Use page_find_range_empty for mmap_find_vma_reserved")
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3310
    Signed-off-by: Bingwu Zhang <xtex@astrafall.org>
    Reviewed-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    (cherry picked from commit f2813e13fe910e01127271a87177a477b9438bc6)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit d9dfd5f425684702b09e0fe135bd3a8041f98b9f
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Mar 3 17:27:18 2026 +0000

    hw/net/xilinx_ethlite: Check for oversized TX packets
    
    The xilinx_ethlite network device wasn't checking that the TX packet
    size set by the guest was within the size of its dual port RAM, with
    the effect that the guest could get it to read off the end of the RAM
    block.
    
    Check the length.  There is no provision in this very simple device
    for reporting errors, so as with various RX errors we just report via
    tracepoint.
    
    This lack of length check has been present since the device was first
    introduced, though the code implementing the tx path has changed
    somewhat since then.
    
    Cc: qemu-stable@nongnu.org
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3317
    Fixes: b43848a1005ce ("xilinx: Add ethlite emulation")
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
    Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
    Message-ID: <20260303172718.437015-1-peter.maydell@linaro.org>
    [PMD: renamed size -> tx_size to avoid shadow=compatible-local error]
    Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    (cherry picked from commit 6595a8d5d17ea1716ddafb34455ec2b29381e232)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 0c5199e52b7cd4c3253ad76cb3ad0faa22acb8ca
Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Date:   Wed Mar 4 16:50:31 2026 +0000

    virtio-gpu: Ensure BHs are invoked only from main-loop thread
    
    QEMU's display GL core is tied to main-loop thread and virtio-gpu
    interacts with display while processing GPU commands. Virtio-gpu BHs
    work in generic AIO context that can be invoked on vCPU thread, while
    GL and UI toolkits are bound to the main-loop thread.
    
    Make virtio-gpu BHs use iohandler AIO context that is handled in a
    main-loop thread only.
    
     0  SDL_GL_MakeCurrent() (libSDL3)
     1  SDL_GL_MakeCurrent_REAL() (libSDL2)
     2  sdl2_gl_make_context_current() (ui/sdl2-gl.c:201)
     3  make_current() (virglrenderer.c:639)
     4  vrend_finish_context_switch() (vrend_renderer.c:11630)
     5  vrend_hw_switch_context() (vrend_renderer.c:11613)
     6  vrend_renderer_force_ctx_0() (vrend_renderer.c:12986)
     7  virgl_renderer_force_ctx_0() (virglrenderer.c:460)
     8  virtio_gpu_virgl_process_cmd() (virtio-gpu-virgl.c:1013)
     9  virtio_gpu_process_cmdq() (virtio-gpu.c:1050)
     10 virtio_gpu_gl_handle_ctrl() (virtio-gpu-gl.c:86)
     11 aio_bh_poll() (util/async.c)
     12 aio_poll() (util/aio-posix.c)
     13 blk_pwrite() (block/block-gen.c:1985)
     14 pflash_update() (pflash_cfi01.c:396)
     15 pflash_write() (pflash_cfi01.c:541)
     16 memory_region_dispatch_write() (system/memory.c:1554)
     17 flatview_write() (system/physmem.c:3333)
     18 address_space_write() (system/physmem.c:3453)
     19 kvm_cpu_exec() (accel/kvm/kall-all.c:3248)
     20 kvm_vcpu_thread_fn() (accel/kvm/kaccel-ops.c:53)
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Message-ID: <20260303151422.977399-8-dmitry.osipenko@collabora.com>
    Message-ID: <20260304165043.1437519-10-alex.bennee@linaro.org>
    Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
    (cherry picked from commit 235f9b36383e4cc7a790bca51eddbe38edd5438c)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit a40b3f664c330bae30b7d9d55028aba6ef75d95d
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Feb 13 07:26:37 2026 -0700

    fdmon-io_uring: check CQ ring directly in gsource_check
    
    gsource_check() only looks at the ppoll revents for the io_uring fd,
    but CQEs can be posted during gsource_prepare()'s io_uring_submit()
    call via kernel task_work processing on syscall exit. These completions
    are already sitting in the CQ ring but the ring fd may not be signaled
    yet, causing gsource_check() to return false.
    
    Add a fallback io_uring_cq_ready() check so completions that arrive
    during submission are dispatched immediately rather than waiting for
    the next ppoll() cycle.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Message-ID: <20260213143225.161043-3-axboe@kernel.dk>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    (cherry picked from commit 961fcc0f22768e7c3432fc645b93dc7cd4932fae)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit f9b1537744b92e45d99648556b934aaaf36b7c82
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Feb 18 15:09:58 2026 -0500

    aio-posix: notify main loop when SQEs are queued
    
    When a vCPU thread handles MMIO (holding BQL), aio_co_enter() runs the
    block I/O coroutine inline on the vCPU thread because
    qemu_get_current_aio_context() returns the main AioContext when BQL is
    held. The coroutine calls luring_co_submit() which queues an SQE via
    fdmon_io_uring_add_sqe(), but the actual io_uring_submit() only happens
    in gsource_prepare() on the main loop thread.
    
    Since the coroutine ran inline (not via aio_co_schedule()), no BH is
    scheduled and aio_notify() is never called. The main loop remains asleep
    in ppoll() with up to a 499ms timeout, leaving the SQE unsubmitted until
    the next timer fires.
    
    Fix this by calling aio_notify() after queuing the SQE. This wakes the
    main loop via the eventfd so it can run gsource_prepare() and submit the
    pending SQE promptly.
    
    This is a generic fix that benefits all devices using aio=io_uring.
    Without it, AHCI/SATA devices see MUCH worse I/O latency since they use
    MMIO (not ioeventfd like virtio) and have no other mechanism to wake the
    main loop after queuing block I/O.
    
    This is usually a bit hard to detect, as it also relies on the ppoll
    loop not waking up for other activity, and micro benchmarks tend not to
    see it because they don't have any real processing time. With a
    synthetic test case that has a few usleep() to simulate processing of
    read data, it's very noticeable. The below example reads 128MB with
    O_DIRECT in 128KB chunks in batches of 16, and has a 1ms delay before
    each batch submit, and a 1ms delay after processing each completion.
    Running it on /dev/sda yields:
    
    time sudo ./iotest /dev/sda
    
    ________________________________________________________
    Executed in   25.76 secs          fish           external
       usr time    6.19 millis  783.00 micros    5.41 millis
       sys time   12.43 millis  642.00 micros   11.79 millis
    
    while on a virtio-blk or NVMe device we get:
    
    time sudo ./iotest /dev/vdb
    
    ________________________________________________________
    Executed in    1.25 secs      fish           external
       usr time    1.40 millis    0.30 millis    1.10 millis
       sys time   17.61 millis    1.43 millis   16.18 millis
    
    time sudo ./iotest /dev/nvme0n1
    
    ________________________________________________________
    Executed in    1.26 secs      fish           external
       usr time    6.11 millis    0.52 millis    5.59 millis
       sys time   13.94 millis    1.50 millis   12.43 millis
    
    where the latter are consistent. If we run the same test but keep the
    socket for the ssh connection active by having activity there, then
    the sda test looks as follows:
    
    time sudo ./iotest /dev/sda
    
    ________________________________________________________
    Executed in    1.23 secs      fish           external
       usr time    2.70 millis   39.00 micros    2.66 millis
       sys time    4.97 millis  977.00 micros    3.99 millis
    
    as now the ppoll loop is woken all the time anyway.
    
    After this fix, on an idle system:
    
    time sudo ./iotest /dev/sda
    
    ________________________________________________________
    Executed in    1.30 secs      fish           external
       usr time    2.14 millis    0.14 millis    2.00 millis
       sys time   16.93 millis    1.16 millis   15.76 millis
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Message-Id: <07d701b9-3039-4f9b-99a2-abeae51146a5@kernel.dk>
    Reviewed-by: Kevin Wolf <kwolf@redhat.com>
    [Generalize the comment since this applies to all vCPU thread activity,
    not just coroutines, as suggested by Kevin Wolf <kwolf@redhat.com>.
    --Stefan]
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    (cherry picked from commit 2ae361ef1d7d526b07ff88d854552e2d009bfb1b)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 8b851e5bb114f795e8f4ffd7712034a45c24dfad
Author: Hanna Czenczek <hreitz@redhat.com>
Date:   Fri Jan 2 16:32:46 2026 +0100

    block/nfs: Do not enter coroutine from CB
    
    The reasoning I gave for why it would be safe to call aio_co_wake()
    despite holding the mutex was wrong: It is true that the current request
    will not re-acquire the mutex, but a subsequent request in the same
    coroutine can.  Because the mutex is a non-coroutine mutex, this will
    result in a deadlock.
    
    Therefore, we must either not enter the coroutine here (only scheduling
    it), or release the mutex around aio_co_wake().  I opt for the former,
    as it is the behavior prior to the offending commit, and so seems safe
    to do.
    
    Fixes: deb35c129b859b9bec70fd42f856a0b7c1dc6e61
           ("nfs: Run co BH CB in the coroutine’s AioContext")
    Buglink: https://gitlab.com/qemu-project/qemu/-/issues/2622#note_2965097035
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
    Message-ID: <20260102153246.154207-1-hreitz@redhat.com>
    Reviewed-by: Kevin Wolf <kwolf@redhat.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    (cherry picked from commit 1d6610099bd7fc159626a38e60a3c84343ff67f7)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit ca8b13eb043c206fe374d5777186c433993cd862
Author: Kevin Wolf <kwolf@redhat.com>
Date:   Wed Mar 4 13:28:00 2026 +0100

    block: Never drop BLOCK_IO_ERROR with action=stop for rate limiting
    
    Commit 2155d2dd introduced rate limiting for BLOCK_IO_ERROR to emit an
    event only once a second. This makes sense for cases in which the guest
    keeps running and can submit more requests that would possibly also fail
    because there is a problem with the backend.
    
    However, if the error policy is configured so that the VM is stopped on
    errors, this is both unnecessary because stopping the VM means that the
    guest can't issue more requests and in fact harmful because stopping the
    VM is an important state change that management tools need to keep track
    of even if it happens more than once in a given second. If an event is
    dropped, the management tool would see a VM randomly going to paused
    state without an associated error, so it has a hard time deciding how to
    handle the situation.
    
    This patch disables rate limiting for action=stop by not relying on the
    event type alone any more in monitor_qapi_event_queue_no_reenter(), but
    checking action for BLOCK_IO_ERROR, too. If the error is reported to the
    guest or ignored, the rate limiting stays in place.
    
    Fixes: 2155d2dd7f73 ('block-backend: per-device throttling of BLOCK_IO_ERROR reports')
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    Message-ID: <20260304122800.51923-1-kwolf@redhat.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    (cherry picked from commit 544ddbb6373d61292a0e2dc269809cd6bd5edec6)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 43e60c88f1d0d9c7b2da766723d34038217dde0b
Author: Dmitry Guryanov <dmitry.guryanov@gmail.com>
Date:   Mon Dec 8 11:55:28 2025 +0300

    block/throttle-groups: fix deadlock with iolimits and muliple iothreads
    
    Details: https://gitlab.com/qemu-project/qemu/-/issues/3144
    
    The function schedule_next_request is called with tg->lock held and
    it may call throttle_group_co_restart_queue, which takes
    tgm->throttled_reqs_lock, qemu_co_mutex_lock may leave current
    coroutine if other iothread has taken the lock. If the next
    coroutine will call throttle_group_co_io_limits_intercept - it
    will try to take the mutex tg->lock which will never be released.
    
    Here is the backtrace of the iothread:
    Thread 30 (Thread 0x7f8aad1fd6c0 (LWP 24240) "IO iothread2"):
     #0  futex_wait (futex_word=0x5611adb7d828, expected=2, private=0) at ../sysdeps/nptl/futex-internal.h:146
     #1  __GI___lll_lock_wait (futex=futex@entry=0x5611adb7d828, private=0) at lowlevellock.c:49
     #2  0x00007f8ab5a97501 in lll_mutex_lock_optimized (mutex=0x5611adb7d828) at pthread_mutex_lock.c:48
     #3  ___pthread_mutex_lock (mutex=0x5611adb7d828) at pthread_mutex_lock.c:93
     #4  0x00005611823f5482 in qemu_mutex_lock_impl (mutex=0x5611adb7d828, file=0x56118289daca "../block/throttle-groups.c", line=372) at ../util/qemu-thread-posix.c:94
     #5  0x00005611822b0b39 in throttle_group_co_io_limits_intercept (tgm=0x5611af1bb4d8, bytes=4096, direction=THROTTLE_READ) at ../block/throttle-groups.c:372
     #6  0x00005611822473b1 in blk_co_do_preadv_part (blk=0x5611af1bb490, offset=15972311040, bytes=4096, qiov=0x7f8aa4000f98, qiov_offset=0, flags=BDRV_REQ_REGISTERED_BUF) at ../block/block-backend.c:1354
     #7  0x0000561182247fa0 in blk_aio_read_entry (opaque=0x7f8aa4005910) at ../block/block-backend.c:1619
     #8  0x000056118241952e in coroutine_trampoline (i0=-1543497424, i1=32650) at ../util/coroutine-ucontext.c:175
     #9  0x00007f8ab5a56f70 in ?? () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:66 from target:/lib64/libc.so.6
     #10 0x00007f8aad1ef190 in ?? ()
     #11 0x0000000000000000 in ?? ()
    
    The lock is taken in line 386:
    (gdb) p tg.lock
    $1 = {lock = {__data = {__lock = 2, __count = 0, __owner = 24240, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
        __size = "\002\000\000\000\000\000\000\000\260^\000\000\001", '\000' <repeats 26 times>, __align = 2}, file = 0x56118289daca "../block/throttle-groups.c",
      line = 386, initialized = true}
    
    The solution is to use tg->lock to protect both ThreadGroup fields and
    ThrottleGroupMember.throttled_reqs. It doesn't seem to be possible
    to use separate locks because we need to first manipulate ThrottleGroup
    fields, then schedule next coroutine using throttled_reqs and after than
    update token field from ThrottleGroup depending on the throttled_reqs
    state.
    
    Signed-off-by: Dmitry Guryanov <dmitry.guryanov@gmail.com>
    Message-ID: <20251208085528.890098-1-dmitry.guryanov@gmail.com>
    Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    (cherry picked from commit d4816177654d59e26ce212c436513f01842eb410)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 61f14858c1599e387aec3c3612b63a49e84078a5
Author: Kevin Wolf <kwolf@redhat.com>
Date:   Thu Feb 19 21:24:46 2026 +0100

    mirror: Fix missed dirty bitmap writes during startup
    
    Currently, mirror disables the block layer's dirty bitmap before its own
    replacement is working. This means that during startup, there is a
    window in which the allocation status of blocks in the source has
    already been checked, but new writes coming in aren't tracked yet,
    resulting in a corrupted copy:
    
    1. Dirty bitmap is disabled in mirror_start_job()
    2. Some request are started in mirror_top_bs while s->job == NULL
    3. mirror_dirty_init() -> bdrv_co_is_allocated_above() runs and because
       the request hasn't completed yet, the block isn't allocated
    4. The request completes, still sees s->job == NULL and skips the
       bitmap, and nothing else will mark it dirty either
    
    One ingredient is that mirror_top_opaque->job is only set after the
    job is fully initialized. For the rationale, see commit 32125b1460
    ("mirror: Fix access of uninitialised fields during start").
    
    Fix this by giving mirror_top_bs access to dirty_bitmap and enabling it
    to track writes from the beginning. Disabling the block layer's tracking
    and enabling the mirror_top_bs one happens in a drained section, so
    there is no danger of races with in-flight requests any more. All of
    this happens well before the block allocation status is checked, so we
    can be sure that no writes will be missed.
    
    Cc: qemu-stable@nongnu.org
    Closes: https://gitlab.com/qemu-project/qemu/-/issues/3273
    Fixes: 32125b14606a ('mirror: Fix access of uninitialised fields during start')
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    Message-ID: <20260219202446.312493-1-kwolf@redhat.com>
    Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
    Tested-by: Jean-Louis Dupond <jean-louis@dupond.be>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    (cherry picked from commit 0f51f9c3420b31bb383e456dd7bf24d3056eeb73)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 11589707ec8ad08a9e45ea9b43d1d800a14d1670
Author: Antoine Damhet <adamhet@scaleway.com>
Date:   Thu Feb 12 17:27:24 2026 +0100

    block/curl: fix concurrent completion handling
    
    curl_multi_check_completion would bail upon the first completed
    transfer even if more completion messages were available thus leaving
    some in flight IOs stuck.
    
    Rework a bit the loop to make the iterations clearer and drop the breaks.
    
    The original hang can be somewhat reproduced with the following command:
    
    $ qemu-img convert -p -m 16 -O qcow2 -c --image-opts \
      'file.driver=https,file.url=https://scaleway.testdebit.info/10G.iso,file.readahead=1M' \
      /tmp/test.qcow2
    
    Fixes: 1f2cead32443 ("curl: Ensure all informationals are checked for completion")
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Antoine Damhet <adamhet@scaleway.com>
    Message-ID: <20260212162730.440855-2-adamhet@scaleway.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    (cherry picked from commit 6f7b0a23a6ea0cc72ad222ab37936248d99d4256)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 86b5130fefbe476f3c0a85b9e136f9e3fd518689
Author: Halil Oktay (oblivionsage) <cookieandcream560@gmail.com>
Date:   Tue Feb 10 13:33:25 2026 +0100

    block/vmdk: fix OOB read in vmdk_read_extent()
    
    Bounds check for marker.size doesn't account for the 12-byte marker
    header, allowing zlib to read past the allocated buffer.
    
    Move the check inside the has_marker block and subtract the marker size.
    
    Fixes: CVE-2026-2243
    Reported-by: Halil Oktay (oblivionsage) <cookieandcream560@gmail.com>
    Signed-off-by: Halil Oktay (oblivionsage) <cookieandcream560@gmail.com>
    Reviewed-by: Kevin Wolf <kwolf@redhat.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
    (cherry picked from commit cfda94eddb6c9c49b66461c950b22845a46a75c9)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 52cb65f9a6a9a7399c545d9f80b5ef40f0cc33af
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Fri Mar 6 09:01:12 2026 +0000

    hw/net/smc91c111: Don't allow negative-length packets
    
    The smc91c111 data frame format in memory (figure 8-1 in the
    datasheet) includes a "byte count" field which is intended to be the
    total size of the data frame, including not just the packet data but
    also the leading and trailing information like the status word and
    the byte count field itself.  It is therefore possible for the guest
    to set this to a value so small that the leading and trailing fields
    won't fit and the packet has effectively a negative area.
    
    We weren't checking for this, with the result that when we subtract 6
    from the length to get the length of the packet proper we end up with
    a negative length, which is then inconsistently handled in the
    qemu_send_packet() code such that we can try to transmit a very large
    amount of data and read off the end of the device's data array.
    
    Treat excessively small length values the same way we do excessively
    large values.  As with the oversized case, the datasheet does not
    describe what happens for this software error case, and there is no
    relevant tx error condition for this, so we just log and drop the
    packet.
    
    Cc: qemu-stable@nongnu.org
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3304
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Message-id: 20260226175549.1319476-1-peter.maydell@linaro.org
    (cherry picked from commit d8e19f8042dcaff8e077292209c8196acb150bdd)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit e944f36993223b4a2f52759941ef7dee4a3a428d
Author: Daniel P. Berrangé <berrange@redhat.com>
Date:   Tue Jan 6 13:45:10 2026 +0000

    io: fix cleanup for websock I/O source data on cancellation
    
    The websock code will create a GSource for tracking completion of the
    handshake process, passing a QIOTask which is freed by the callback
    when it completes, which means when a source is cancelled, nothing is
    free'ing the task.
    
    Switch to provide a data free callback to the GSource, which ensures
    the QIOTask is always freed even when the main event callback never
    fires.
    
    Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3114
    Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
    (cherry picked from commit 9545c059f77e3f814fcbaba83203572ea655c50e)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit f8943633a91f36b4f7372cd8598209425189df4a
Author: Daniel P. Berrangé <berrange@redhat.com>
Date:   Tue Jan 6 13:45:10 2026 +0000

    io: fix cleanup for TLS I/O source data on cancellation
    
    The TLS code will create a GSource for tracking completion of the
    handshake process, passing a QIOChannelTLSData struct that contains
    various data items. The data struct is freed by the callback when
    it completes, which means when a source is cancelled, nothing is
    free'ing the data struct or its contents.
    
    Switch to provide a data free callback to the GSource, which ensures
    the QIOChannelTLSData struct is always freed even when the main event
    callback never fires.
    
    Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3114
    Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
    (cherry picked from commit d39d0f3acdd7c1bb275db7e97b511f98254ecd9f)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 68e031345a022643896b3f4f95391cecdac592fe
Author: Daniel P. Berrangé <berrange@redhat.com>
Date:   Tue Jan 6 16:08:49 2026 +0000

    io: separate freeing of tasks from marking them as complete
    
    The original design of QIOTask was intended to simplify lifecycle
    management by automatically freeing it when the task was marked as
    complete. This overlooked the fact that when a QIOTask is used in
    combination with a GSource, there may be times when the source
    callback is never invoked. This is typically when a GSource is
    released before any I/O event arrives. In such cases it is not
    desirable to mark a QIOTask as complete, but it still needs to be
    freed. To satisfy this, the task must be released manually.
    
    Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
    (cherry picked from commit 163cd0ae1182e67509b271f244a73dfd938337b9)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 0deef852924f58c429b886eb4a2ca9ce0b8b381c
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Feb 12 15:07:53 2026 +0000

    target/ppc/translate: Fix TCG debug assert translating CLRBWIBC
    
    The test case in the ppe42 functional test triggers a TCG debug
    assertion, which causes the test to fail in an --enable-debug
    build or when the sanitizers are enabled:
    
    #6  0x00007ffff4a3b517 in __assert_fail
        (assertion=0x5555562e7589 "!temp_readonly(ots)", file=0x5555562e5b23 "../../tcg/tcg.c", line=4928, function=0x5555562e8900 <__PRETTY_FUNCTION__.23> "tcg_reg_alloc_mov") at ./assert/assert.c:105
    #7  0x0000555555cc2189 in tcg_reg_alloc_mov (s=0x7fff60000b70, op=0x7fff600126f8) at ../../tcg/tcg.c:4928
    #8  0x0000555555cc74e0 in tcg_gen_code (s=0x7fff60000b70, tb=0x7fffa802f540, pc_start=4294446080) at ../../tcg/tcg.c:6667
    #9  0x0000555555d02abe in setjmp_gen_code
        (env=0x555556cbe610, tb=0x7fffa802f540, pc=4294446080, host_pc=0x7fffeea00c00, max_insns=0x7fffee9f9d74, ti=0x7fffee9f9d90)
        at ../../accel/tcg/translate-all.c:257
    #10 0x0000555555d02d75 in tb_gen_code (cpu=0x555556cba590, s=...) at ../../accel/tcg/translate-all.c:325
    #11 0x0000555555cf5922 in cpu_exec_loop (cpu=0x555556cba590, sc=0x7fffee9f9ee0) at ../../accel/tcg/cpu-exec.c:970
    #12 0x0000555555cf5aae in cpu_exec_setjmp (cpu=0x555556cba590, sc=0x7fffee9f9ee0) at ../../accel/tcg/cpu-exec.c:1016
    #13 0x0000555555cf5b4b in cpu_exec (cpu=0x555556cba590) at ../../accel/tcg/cpu-exec.c:1042
    #14 0x0000555555d1e7ab in tcg_cpu_exec (cpu=0x555556cba590) at ../../accel/tcg/tcg-accel-ops.c:82
    #15 0x0000555555d1ff97 in rr_cpu_thread_fn (arg=0x555556cba590) at ../../accel/tcg/tcg-accel-ops-rr.c:285
    #16 0x00005555561586c9 in qemu_thread_start (args=0x555556ee3c90) at ../../util/qemu-thread-posix.c:393
    #17 0x00007ffff4a9caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
    #18 0x00007ffff4b29c6c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
    
    This can be reproduced "by hand":
    
     ./build/clang/qemu-system-ppc -display none -vga none \
        -machine ppe42_machine -serial stdio \
        -device loader,file=$HOME/.cache/qemu/download/03c1ac0fb7f6c025102a02776a93b35101dae7c14b75e4eab36a337e39042ea8 \
        -device loader,addr=0xfff80040,cpu-num=0
    
    (assuming you have the image file from the functional test
    in your local cache).
    
    This happens for this input:
    
    IN:
    0xfff80c00:  07436004  .byte    0x07, 0x43, 0x60, 0x04
    
    which generates (among other things):
    
     not_i32 $0x80000,$0x80000
    
    which the TCG optimization pass turns into:
    
     mov_i32 $0x80000,$0xfff7ffff             dead: 1  pref=0xffff
    
    and where we then assert because we tried to write to a constant.
    
    This happens for the CLRBWIBC instruction which ends up in
    do_mask_branch() with rb_is_gpr false and invert true.  In this case
    we will generate code that sets mask to a tcg_constant_tl() but then
    uses it as the LHS in tcg_gen_not_tl().
    
    Fix the assertion by doing the invert in the translate time C code
    for the "mask is constant" case.
    
    Cc: qemu-stable@nongnu.org
    Fixes: f7ec91c23906 ("target/ppc: Add IBM PPE42 special instructions")
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Link: https://lore.kernel.org/qemu-devel/20260212150753.1749448-1-peter.maydell@linaro.org
    Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
    (cherry picked from commit 78c6b6010ce7cfa54874dda514e694640b76f1e4)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 438b752c76a7aff3e930d8ddb096ba555c9bcc67
Author: Bernhard Beschow <shentey@gmail.com>
Date:   Tue Feb 24 00:39:25 2026 +0100

    target/i386/emulate/x86_decode: Actually use stream in decode_instruction_stream()
    
    Compared to decode_instruction(), decode_instruction_stream() has an additional
    stream parameter which avoids some guest memory accesses during instruction
    decoding. Both functions defer the actual work to decode_opcode() which would
    set the stream pointer to zero such that decode_instruction_stream() essentially
    behaved like decode_instruction(). Given that all callers of
    decode_instruction_stream() properly zero-initialize the decode parameter, the
    memset() call can be moved into decode_instruction() which is the only other
    user of decode_opcode(). This preserves the non-zero stream pointer which
    avoids extra guest memory accesses.
    
    Fixes: 1e25327b244a ("target/i386/emulate: Allow instruction decoding from stream")
    cc: qemu-stable
    Signed-off-by: Bernhard Beschow <shentey@gmail.com>
    Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
    Reviewed-by: Wei Liu (Microsoft) <wei.liu@kernel.org>
    Tested-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
    Link: https://lore.kernel.org/r/20260223233950.96076-4-mohamed@unpredictable.fr
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    (cherry picked from commit 1b93832f55927b1b76a6587ca75a5a35676188de)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 32c1fc948e5b06beb368d32fe5f99b3fb039c149
Author: Bernhard Beschow <shentey@gmail.com>
Date:   Tue Feb 24 00:39:24 2026 +0100

    target/i386/hvf/x86_mmu: Fix compiler warning
    
    When reusing the code in WHPX, GCC emits the following warning when compiling
    for i386-softmmu under MSYS2:
    
      In file included from ../src/target/i386/emulate/x86_mmu.c:20:
      ../src/target/i386/emulate/x86_mmu.c: In function 'vmx_write_mem':
      ../src/target/i386/emulate/x86_mmu.c:251:25: error: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'target_ulong' {aka 'unsigned int'} [-Werror=format=]
        251 |             VM_PANIC_EX("%s: mmu_gva_to_gpa %llx failed\n", __func__, gva);
            |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            ~~~
            |                                                                       |
            |                                                                       target_ulong {aka unsigned int}
      ../src/target/i386/emulate/panic.h:34:12: note: in definition of macro 'VM_PANIC_EX'
         34 |     printf(__VA_ARGS__); \
            |            ^~~~~~~~~~~
      ../src/target/i386/emulate/x86_mmu.c:251:48: note: format string is defined here
        251 |             VM_PANIC_EX("%s: mmu_gva_to_gpa %llx failed\n", __func__, gva);
            |                                             ~~~^
            |                                                |
            |                                                long long unsigned int
            |                                             %x
    
    Fix the warning by reusing the target-specific macro TARGET_FMT_lx which exists
    for this exact purpose.
    
    Fixes: c97d6d2cdf97 ("i386: hvf: add code base from Google's QEMU repository")
    cc: qemu-stable
    Signed-off-by: Bernhard Beschow <shentey@gmail.com>
    Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Reviewed-by: Wei Liu (Microsoft) <wei.liu@kernel.org>
    Link: https://lore.kernel.org/r/20260223233950.96076-3-mohamed@unpredictable.fr
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    (cherry picked from commit 529e5e7643078e19d65e694f51cad64be49090ab)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 17ec370a79041e63a6a4807fde84963aa617ac6a
Author: Bernhard Beschow <shentey@gmail.com>
Date:   Tue Feb 24 00:39:23 2026 +0100

    target/i386/emulate/x86_decode: Fix compiler warning
    
    When compiling for i386-softmmu under MSYS2, GCC emits the following warning:
    
      In function 'get_reg_val',
          inlined from 'calc_modrm_operand64' at ../src/target/i386/emulate/x86_decode.c:1796:15:
      ../src/target/i386/emulate/x86_decode.c:1703:5: error: 'memcpy' forming offset [4, 7] is out of the bounds [0, 4] of object 'val' with type 'target_ulong' {aka 'unsigned int'} [-Werror=array-bounds=]
       1703 |     memcpy(&val,
            |     ^~~~~~~~~~~~
       1704 |            get_reg_ref(env, reg, rex_present, is_extended, size),
            |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       1705 |            size);
            |            ~~~~~
      ../src/target/i386/emulate/x86_decode.c: In function 'calc_modrm_operand64':
      ../src/target/i386/emulate/x86_decode.c:1702:18: note: 'val' declared here
       1702 |     target_ulong val = 0;
            |                  ^~~
    
    In the calc_modrm_operand64() case the compiler sees size == 8 to be mem-copied
    to a target_ulong variable which is only 4 bytes wide in case of i386-softmmu.
    Note that when size != 1, get_reg_ref() always returns a pointer to an 8 byte
    register, regardless of the target_ulong size. Fix the compiler warning by
    always providing 8 bytes of storage by means of uint64_t.
    
    Fixes: 77a2dba45cc9 ("target/i386/emulate: stop overloading decode->op[N].ptr")
    cc: qemu-stable
    Signed-off-by: Bernhard Beschow <shentey@gmail.com>
    Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
    Reviewed-by: Wei Liu (Microsoft) <wei.liu@kernel.org>
    Link: https://lore.kernel.org/r/20260223233950.96076-2-mohamed@unpredictable.fr
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    (cherry picked from commit c86bca1671e9e4161e2a93d73514384de510bbf3)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 7426a375bcb6e68abc9a7da49f40bcf941e8c7b1
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Thu Feb 5 08:47:35 2026 -0800

    hw/i386/vmmouse: Fix hypercall clobbers
    
    Fedora QA reported the following kernel panic:
    
      BUG: unable to handle page fault for address: 0000000040003e54
      #PF: supervisor write access in kernel mode
      #PF: error_code(0x0002) - not-present page
      PGD 1082ec067 P4D 0
      Oops: Oops: 0002 [#1] SMP NOPTI
      CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-0.rc4.260108gf0b9d8eb98df.34.fc43.x86_64 #1 PREEMPT(lazy)
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025
      RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90
      Code: 48 83 c4 20 5b e9 69 f0 fc fe 8b 05 a0 c1 b2 01 85 c0 74 23 b8 68 58 4d 56 b9 27 00 00 00 31 d2 bb 04 00 00 00 66 ba 58 56 ed <89> 1f 89 0e 41 89 10 5b e9 3c f0 fc fe 6a 00 49 89 f9 45 31 c0 31
      RSP: 0018:ff5eeb3240003e40 EFLAGS: 00010046
      RAX: 0000000000000000 RBX: 000000000000ffca RCX: 000000000000ffac
      RDX: 0000000000000000 RSI: 0000000040003e58 RDI: 0000000040003e54
      RBP: ff1e05f3c1204800 R08: ff5eeb3240003e5c R09: 000000009d899c41
      R10: 000000000000003d R11: ff5eeb3240003ff8 R12: 0000000000000000
      R13: 00000000000000ff R14: ff1e05f3c02f9e00 R15: 000000000000000c
      FS:  0000000000000000(0000) GS:ff1e05f489e40000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000040003e54 CR3: 000000010841d002 CR4: 0000000000771ef0
      PKRU: 55555554
      Call Trace:
       <IRQ>
       vmmouse_report_events+0x13e/0x1b0
       psmouse_handle_byte+0x15/0x60
       ps2_interrupt+0x8a/0xd0
       ...
    
    It was triggered by dereferencing a bad pointer (RDI) immediately after
    a VMware hypercall for VMWARE_CMD_ABSPOINTER_DATA in the vmmouse driver:
    
      ffffffff82135070 <vmware_hypercall4.constprop.0>:
      ...
      ffffffff821350ac:       b8 68 58 4d 56          mov    $0x564d5868,%eax
      ffffffff821350b1:       b9 27 00 00 00          mov    $0x27,%ecx
      ffffffff821350b6:       31 d2                   xor    %edx,%edx
      ffffffff821350b8:       bb 04 00 00 00          mov    $0x4,%ebx
      ffffffff821350bd:       66 ba 58 56             mov    $0x5658,%dx
      ffffffff821350c1:       ed                      in     (%dx),%eax     <-- hypercall
      ffffffff821350c2:       89 1f                   mov    %ebx,(%rdi)    <-- crash
    
    Reading the kernel disassembly shows that RDI should contain the value
    of a valid kernel stack address here (0xff5eeb3240003e54).  Instead it
    contains 0x40003e54, suggesting the hypervisor cleared the upper 32
    bits.
    
    And indeed, Alexey discovered that QEMU's vmmouse_get_data() and
    vmmouse_set_data() are only saving/restoring the lower 32 bits, while
    clearing the upper 32.  Fix that by changing the type of the saved data
    array from uint32_t to uint64_t.
    
    Fixes: 548df2acc6fc ("VMMouse Emulation, by Anthony Liguori.")
    Reported-by: Justin Forbes <jforbes@fedoraproject.org>
    Debugged-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Link: https://lore.kernel.org/r/c508fc1d4a4ccd8c9fb1e51b71df089e31115a53.1770309998.git.jpoimboe@kernel.org
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3293
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    (cherry picked from commit 48c8916aec4319efc60324d9d971831a8a1d6350)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit f577bc677f540b5d1f7e43cbeee85525ab656b27
Author: Christian Schoenebeck <qemu_oss@crudebyte.com>
Date:   Sun Feb 15 13:44:50 2026 +0100

    hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs synth driver
    
    Renaming files/dirs is only supported by path-based fs drivers. EOPNOTSUPP
    should be returned on any renaming attempt for not path-based fs drivers.
    This was already the case for 9p "Trename" request type. However for 9p
    request types "Trenameat" and "Twstat" this was yet missing.
    
    So fix this by checking in Twstat and Trenameat request handlers whether
    the fs driver in use is really path based, if not return EOPNOTSUPP and
    abort further handling of the request.
    
    This fixes a crash with the 9p "synth" fs driver which is not path-based.
    
    The crash happened because the synth driver stores and expects a raw
    V9fsSynthNode pointer instead of a C-string on V9fsPath.data. So the
    C-string delivered by 9p server to synth fs driver was incorrectly
    casted to a V9fsSynthNode pointer, eventually causing a segfault.
    
    Reported-by: Oliver Chang <ochang@google.com>
    Fixes: https://issues.oss-fuzz.com/issues/477990727
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3298
    Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
    Reviewed-by: Greg Kurz <groug@kaod.org>
    Link: https://lore.kernel.org/qemu-devel/E1vrbaP-000Gqb-B3@kylie.crudebyte.com/
    (cherry picked from commit b72d15f47cbd2fc93580f33fa86a7e23595a68dd)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit cdafefe5aebc1d57144badf935f912c01f948dbd
Author: Richie Buturla <richie@linux.ibm.com>
Date:   Wed Feb 11 16:44:50 2026 +0100

    hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()
    
    A data race between v9fs_mark_fids_unreclaim() and v9fs_path_copy()
    causes an inconsistent read of fidp->path. In v9fs_path_copy(), the
    path size is set before the data pointer is allocated, creating a
    window where size is non-zero but data is NULL.
    
    v9fs_co_open2() holds a write lock during path modifications,
    but v9fs_mark_fids_unreclaim() was not acquiring a read
    lock, allowing it to race.
    
    Fix by holding the path read lock during FID table iteration.
    
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3300
    Signed-off-by: Richie Buturla <richie@linux.ibm.com>
    Link: https://lore.kernel.org/qemu-devel/20260211154450.254338-1-richie@linux.ibm.com/
    Fixes: 7a46274529 ("hw/9pfs: Add file descriptor reclaim support")
    Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
    (cherry picked from commit c96f6d2398a9dc068fa82088ea43020a52e2b26d)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit b0560afef64310ee957b297fcb70c26beb2b0d5d
Author: Alex Bennée <alex.bennee@linaro.org>
Date:   Thu Feb 26 11:27:18 2026 +0000

    target/arm: set the correct TI bits for WFIT traps
    
    The WFIT trap should be reported as 0b10.
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
    Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org>
    Message-id: 20260220171945.1065102-1-alex.bennee@linaro.org
    Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    (cherry picked from commit 662fd548a027c9362df71ebfc0c9cdd7b1f349fb)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 7e64af64631f46e5492b5761ebc2fab5f4a0879c
Author: Weixie Cui <cuiweixie@gmail.com>
Date:   Thu Feb 26 11:27:18 2026 +0000

    hw/ssi/xilinx_spips: Reset TX FIFO in reset
    
    In xilinx_spips_reset() and xlnx_zynqmp_qspips_reset() a cut and
    paste error meant we reset the RX FIFO twice and the TX FIFO not at
    all.  Correct this to reset both FIFOs.
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Weixie Cui <cuiweixie@gmail.com>
    Reviewed-by: Thomas Huth <thuth@redhat.com>
    Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Message-id: 20260223095905.67709-1-cuiweixie@gmail.com
    [Rewrote commit message]
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    (cherry picked from commit 669683cf1414ce442d2faea160dbc69747aef007)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit dc9f0565a20b4366e17f661a54fbf5bd0d7f3fe1
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Sun Jan 11 18:49:15 2026 +0000

    hw/misc/virt_ctrl: Fix incorrect trace event in read operation
    
    The virt_ctrl_read() function currently invokes trace_virt_ctrl_write()
    instead of trace_virt_ctrl_read(). This results in read operations
    appearing as write operations in the trace output, which is misleading
    during debugging and analysis.
    
    Replace the incorrect trace call with the proper read-specific trace
    event to accurately reflect the hardware behavior.
    
    Fixes: 0791bc02b8fb ("m68k: add a system controller")
    Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Message-ID: <20260111184915.1363318-1-visitorckw@gmail.com>
    Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    (cherry picked from commit 8608ed356ef90815cc5bcf04fcdbde987fd24bca)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 298986525140149bd749c236c17cfbb507c69e23
Author: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Date:   Fri Feb 20 11:40:16 2026 +0200

    virtio-snd: tighten read amount in in_cb
    
    The amount of bytes to read passed to AUD_read() should never surpass
    the maximum available buffer length. Tighten the current amount by
    MIN(<amount>, max_size - <existing size>).
    
    Cc: qemu-stable@nongnu.org
    Fixes: 98e77e3dd8dd6e7aa9a7dffa60f49c8c8a49d4e3 ("virtio-snd: add max size bounds check in input cb")
    Reported-by: DARKNAVY <vr@darknavy.com>
    Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260220-virtio-snd-series-v1-5-207c4f7200a2@linaro.org>
    (cherry picked from commit 7994203bb1b83a6604f3ab00fe9598909bb66164)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit a730f98a7a199706c44dd86a39d961e80e2ad18f
Author: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Date:   Fri Feb 20 11:40:15 2026 +0200

    virtio-snd: fix max_size bounds check in input cb
    
    In 98e77e3d we calculated the max size and checked that each buffer is smaller than it.
    
    We neglected to subtract the size of the virtio_snd_pcm_status header
    from the max size, and max_size was thus larger than the correct value,
    leading to potential OOB writes.
    
    If the buffer cannot fit the header or can fit only the header, return
    the buffer immediately.
    
    Cc: qemu-stable@nongnu.org
    Fixes: 98e77e3dd8dd6e7aa9a7dffa60f49c8c8a49d4e3 ("virtio-snd: add max size bounds check in input cb")
    Reported-by: DARKNAVY <vr@darknavy.com>
    Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260220-virtio-snd-series-v1-4-207c4f7200a2@linaro.org>
    (cherry picked from commit bcb53328aa70023f1405fade4e253e7f77567261)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit d84fbf241d0322f19adfbe466c60bed5f50de262
Author: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Date:   Fri Feb 20 11:40:14 2026 +0200

    virtio-snd: handle 5.14.6.2 for PCM_INFO properly
    
    The section 5.14.6.2 of the VIRTIO spec says:
    
      5.14.6.2 Driver Requirements: Item Information Request
    
      - The driver MUST NOT set start_id and count such that start_id +
        count is greater than the total number of particular items that is
        indicated in the device configuration space.
    
      - The driver MUST provide a buffer of sizeof(struct virtio_snd_hdr) +
        count * size bytes for the response.
    
    While we performed some check for the second requirement, it failed to
    check for integer overflow.
    
    Add also a check for the first requirement, which should limit exposure
    to any overflow, since realistically the number of streams will be low
    enough in value such that overflow is improbable.
    
    Cc: qemu-stable@nongnu.org
    Reported-by: 罗铭源 <myluo24@m.fudan.edu.cn>
    Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260220-virtio-snd-series-v1-3-207c4f7200a2@linaro.org>
    (cherry picked from commit 61679d7dcfa2dffc8fb115aa19b09e0e7cf5ea5c)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 421123a6914b68547229680c3bf989c10ea0f984
Author: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Date:   Fri Feb 20 11:40:13 2026 +0200

    virtio-snd: remove TODO comments
    
    Replying with a VIRTIO_SND_S_BAD_MSG error does not warrant a device
    reset. Instead, a device reset happens when the driver requests it from the
    transport.
    
    Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260220-virtio-snd-series-v1-2-207c4f7200a2@linaro.org>
    (cherry picked from commit 34238f078a04f24b91199249b83846ab082b4e05)
    (Mjt: pick this one up so the next commit applies cleanly)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit f402cbe224337a015bc8567c19b854c4f020a6d6
Author: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Date:   Sat Feb 14 13:33:36 2026 +0900

    virtio-gpu-virgl: Add virtio-gpu-virgl-hostmem-region type
    
    Commit e27194e087ae ("virtio-gpu-virgl: correct parent for blob memory
    region") made the name member of MemoryRegion unset, causing a NULL
    pointer dereference[1]:
    > Thread 2 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
    > (gdb) bt
    > #0  0x00007ffff56565e2 in __strcmp_evex () at /lib64/libc.so.6
    > #1  0x0000555555841bdb in find_fd (head=0x5555572337d0 <cpr_state>,
    > name=0x0, id=0) at ../migration/cpr.c:68
    > #2  cpr_delete_fd (name=name@entry=0x0, id=id@entry=0) at
    > ../migration/cpr.c:77
    > #3  0x000055555582290a in qemu_ram_free (block=0x7ff7e93aa7f0) at
    > ../system/physmem.c:2615
    > #4  0x000055555581ae02 in memory_region_finalize (obj=<optimized out>)
    > at ../system/memory.c:1816
    > #5  0x0000555555a70ab9 in object_deinit (obj=<optimized out>,
    > type=<optimized out>) at ../qom/object.c:715
    > #6  object_finalize (data=0x7ff7e936eff0) at ../qom/object.c:729
    > #7  object_unref (objptr=0x7ff7e936eff0) at ../qom/object.c:1232
    > #8  0x0000555555814fae in memory_region_unref (mr=<optimized out>) at
    > ../system/memory.c:1848
    > #9  flatview_destroy (view=0x555559ed6c40) at ../system/memory.c:301
    > #10 0x0000555555bfc122 in call_rcu_thread (opaque=<optimized out>) at
    > ../util/rcu.c:324
    > #11 0x0000555555bf17a7 in qemu_thread_start (args=0x555557b99520) at
    > ../util/qemu-thread-posix.c:393
    > #12 0x00007ffff556f464 in start_thread () at /lib64/libc.so.6
    > #13 0x00007ffff55f25ac in __clone3 () at /lib64/libc.so.6
    
    The intention of the aforementioned commit is to prevent a MemoryRegion
    from parenting itself while its references is counted indendependently
    of the device. To achieve the same goal, add a type of QOM objects that
    count references and parent MemoryRegions.
    
    [1] https://lore.kernel.org/qemu-devel/4eb93d7a-1fa9-4b3c-8ad7-a2eb64f025a0@collabora.com/
    
    Cc: qemu-stable@nongnu.org
    Fixes: e27194e087ae ("virtio-gpu-virgl: correct parent for blob memory region")
    Fixes: be88ad424c0b ("virtio-gpu-virgl: correct parent for blob memory region") for 10.2.x
    Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
    Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Tested-by: Joelle van Dyne <j@getutm.app>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260214-region-v1-1-229f00ae1f38@rsg.ci.i.u-tokyo.ac.jp>
    (cherry picked from commit b2a279094c3b86667969cc645f7fb1087e08dd19)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 22687ae317ec2e299918ce1a1eac5c7a2f2ecca6
Author: Helge Deller <deller@gmx.de>
Date:   Wed Feb 18 17:05:05 2026 +0100

    hw/hppa: Add BMC on 64-bit machines only
    
    Prevent adding the BMC with it's serial ports on 32-bit machines, even
    if they have a PCI bus like the B160L. This fixes boot problems with
    HP-UX on B160L.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Fixes: 557bc5260cfd ("hw/hppa: PCI devices depend on availability of PCI bus")
    Cc: qemu-stable@nongnu.org
    Reviewed-by: Anton Johansson <anjo@rev.ng>
    (cherry picked from commit 16786eb7bf8644398707e64fff12e4c9564ec131)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 5fc003f542122e0cf4aeb0789d3b119cb9851bfa
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Feb 18 18:40:13 2026 +0000

    target/arm: Don't let 'sme=on' downgrade SME
    
    In our handling of the boolean 'sme' CPU property, we write this 0/1
    value directly to ID_AA64PFR1_EL1.SME.  This worked when the only
    valid values in that field were 0 (for no SME) and 1 (for SME1).
    However, with the addition of SME2 the SME field can now also read 2.
    This means that "-cpu max,sme=on" will result in an inconsistent set
    of ID registers, where ID_AA64PFR1_EL1.SME claims SME1 but
    ID_AA64SMFR0_EL1.SMEver claims SME2p1.  This isn't a valid thing to
    report, and confuses Linux into reporting SME2 to userspace but not
    actually enabling userspace access for it.
    
    Fix this bug by having arm_cpu_sme_finalize() fix up the
    ID_AA64PFR1_EL1.SME field to match ID_AA64SMFR0.SMEver.  This means
    the "sme" property's semantics are "off" for "no SME" and "on" for
    "enable at whatever the default SME version this CPU provides is".
    
    Update the documentation to clarify what 'sve=on' and 'sme=on' do.
    (We don't have the equivalent bug for 'sve=on' because
    ID_AA64PFR0_EL1.SVE only has 0 and 1 as valid values, but the
    semantics of the property are the same.)
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
    Message-id: 20260202133353.2231685-6-peter.maydell@linaro.org
    (cherry picked from commit aeb3c147fc4a1eb9a73f9f10923fc06def088aeb)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit aeaff51f5838be2da82f70b5834b893fe0109ab5
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Feb 18 18:40:13 2026 +0000

    target/arm/tcg: Allow SVE RAX1 in SME2p1 streaming mode
    
    The SVE RAX1 instruction is permitted in SME streaming mode starting
    from SME2p1.  We forgot to allow this relaxation when we implemented
    SME2p1.
    
    Cc: qemu-stable@nongnu.org
    Fixes: 7b1613a1020d2 ("target/arm: Enable FEAT_SME2p1 on -cpu max")
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Message-id: 20260202133353.2231685-5-peter.maydell@linaro.org
    (cherry picked from commit 433097a2242120918090201129e5fbb8e16b3e34)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit aa9c49d19e3a841575351e9329fb73467919f436
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Feb 18 18:40:13 2026 +0000

    target/arm: Fix feature check in DO_SVE2_RRX, DO_SVE2_RRX_TB
    
    In the macros DO_SVE2_RRX and DO_SVE2_RRX_TB we use the
    feature check aa64_sve, thus exposing this set of instructions
    in SVE as well as SVE2. Use aa64_sve2 instead, so they UNDEF
    on an SVE1-only CPU as they should.
    
    Strictly, the condition here should be "SVE2 or SME"; but we
    will correct that in a following commit with all the other
    missing "or SME" checks.
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
    Message-id: 20260202133353.2231685-4-peter.maydell@linaro.org
    (cherry picked from commit ee5bf0962ed6e0eb42d6bc9bfb3687f2408e3580)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 188b8070ce675764afa8143272f3496c7c4df3b5
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Feb 18 18:40:13 2026 +0000

    target/arm: Account for SME in aarch64_sve_narrow_vq() assertion
    
    In aarch64_sve_narrow_vq() we assert that the new VQ is within
    the maximum supported range for the CPU. We forgot to update
    this to account for SME, which might have a different maximum.
    
    Update the assert to permit any VQ which is valid for either
    SVE or SME.
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Message-id: 20260202133353.2231685-2-peter.maydell@linaro.org
    (cherry picked from commit 42eab40a12f12f044a5ca7b7d889d9a1f0d172ee)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 0e311e683f5a4592dfbb8a975a7d561f3e8b435a
Author: Jamin Lin <jamin_lin@aspeedtech.com>
Date:   Tue Feb 10 02:43:32 2026 +0000

    hw/i2c/aspeed_i2c: Fix out-of-bounds read in I2C MMIO handlers
    
    The ASPEED I2C controller exposes a per-bus MMIO window of 0x80 bytes on
    AST2600/AST1030/AST2700, but the backing regs[] array was sized for only
    28 dwords (0x70 bytes). This allows guest reads in the range [0x70..0x7f]
    to index past the end of regs[].
    
    Fix this by:
    - Sizing ASPEED_I2C_NEW_NUM_REG to match the 0x80-byte window
      (0x80 >> 2 = 32 dwords).
    - Avoiding an unconditional pre-read from regs[] in the legacy/new read
      handlers. Initialize the return value to -1 and only read regs[] for
      offsets that are explicitly handled/valid, leaving invalid offsets to
      return -1 with a guest error log.
    
    Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3290
    Reviewed-by: Cédric Le Goater <clg@redhat.com>
    Link: https://lore.kernel.org/qemu-devel/20260210024331.3984696-2-jamin_lin@aspeedtech.com
    Signed-off-by: Cédric Le Goater <clg@redhat.com>
    (cherry picked from commit c2c5beec42bf9872b37e78b9e259132df7435cb5)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 713e807357f980958013a166141ccc547487ecce
Author: Alex Bradbury <asb@igalia.com>
Date:   Tue Dec 2 23:05:57 2025 +0000

    docs/about/emulation: Add documentation for hotblocks plugin arguments
    
    Currently just 'inline'.
    
    Signed-off-by: Alex Bradbury <asb@igalia.com>
    Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
    Link: https://lore.kernel.org/qemu-devel/35128cc5a86a0c18418f9d3150fb8771c54ef7d8.1753857212.git.asb@igalia.com
    Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
    (cherry picked from commit e4ed74c9aef68cb2e7c10c2b7597fee5491a506a)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit cb327d638f414b05651dc0e6f18e6419623efac1
Author: Alex Bradbury <asb@igalia.com>
Date:   Tue Dec 2 23:05:56 2025 +0000

    contrib/plugins/hotblocks: Print uint64_t with PRIu64 rather than PRId64
    
    qemu_plugin_u64_sum returns a uint64_t, so PRIu64 is the correct format
    specifier.
    
    Signed-off-by: Alex Bradbury <asb@igalia.com>
    Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
    Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
    Link: https://lore.kernel.org/qemu-devel/5d26c9d99ee87ac4a4034ff64e3d8881253eedf3.1753857212.git.asb@igalia.com
    Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
    (cherry picked from commit e777f6ab91406884136b5679a9d64124832668d8)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 85327403337a2a93334fc2361a8cbc6c2bc6a03f
Author: Alex Bradbury <asb@igalia.com>
Date:   Tue Dec 2 23:05:55 2025 +0000

    contrib/plugins/hotblocks: Fix off by one error in iteration of sorted blocks
    
    The logic to iterate over the hottest blocks will never reach the last
    item in the list, as it checks `it->next != NULL` before entering the
    loop. It's hard to trigger this off-by-one error with the default
    limit=20, but it is a bug and is problematic if that default is changed
    to something larger.
    
    Signed-off-by: Alex Bradbury <asb@igalia.com>
    Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
    Link: https://lore.kernel.org/qemu-devel/f1ba2e57c6126472c0c8310774009f2455efc370.1753857212.git.asb@igalia.com
    Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
    (cherry picked from commit 1c1e45fcd66269f8a6dbd97fd7b8267d8f6f58af)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit d8b3ae8088df9648e289e68856294c3633fdf61a
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Sat Feb 14 12:21:06 2026 +0300

    d/control: build utils on powerpc too

commit 666d73d2222206d53c2d3e4cf7189f53c3c9d67c
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Fri Feb 13 10:30:35 2026 +0300

    update changelog; upload version 10.2.1+ds-1 to unstable

commit 12f10b85c7485003a4eece26907773ffe898fb9a
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Fri Feb 13 10:32:04 2026 +0300

    d/control.mk: checked-version=10.2.1

commit 921f98a60e8938ca3033491725c066dd46085257
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Fri Feb 13 10:17:23 2026 +0300

    - fix-PIRQ-bounds-check-in-xen_physdev_map_pirq-CVE-2026-0665.patch

commit 240581e26fb23c1ecc1d9a2e0ded2c36c2a19e2f
Merge: 108e800e2 cc25a61ad
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Fri Feb 13 10:15:36 2026 +0300

    Update upstream source from tag 'upstream/10.2.1+ds'
    
    Update to upstream version '10.2.1+ds'
    with Debian dir ad3107d4110f6c99251707bba2223c1ebf5a6905

commit cc25a61ad0a661190697b353603377375a06e431
Merge: b9fb52215 2d3df8abc
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Fri Feb 13 10:15:13 2026 +0300

    New upstream version 10.2.1+ds

commit 2d3df8abca265c9bcc9e438d691d561592060998
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Thu Feb 12 15:15:05 2026 +0300

    Update version for 10.2.1 release
    
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 63a76e01238c8a3cc2c02f6a12ec53c2ab844a7a
Author: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Date:   Thu Dec 4 12:50:17 2025 +0200

    scripts/qemugdb: timers: Fix KeyError in 'qemu timers' command
    
    Currently invoking 'qemu timers' command results into: "gdb.error: There
    is no member named last".  Let's remove the legacy 'last' field from
    QEMUClock, as it was removed in v4.2.0 by the commit 3c2d4c8aa6a
    ("timer: last, remove last bits of last").
    
    Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 20251204105019.455060-3-andrey.drobyshev@virtuozzo.com
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    (cherry picked from commit 80c97930a93c32e2e666f5420af2d5734021a135)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit b5ce6809b4b47e6cd414c9ce9449b114cd5c657f
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Feb 2 10:17:53 2026 +0100

    Revert "tcg/user: do not set exit_request gratuitously"
    
    This reverts commit b422a7bff64eaf55b8250225533ca1df42c3777e.
    
    The reporter says "The commit breaks go; if you run go build in a loop,
    it eventually hangs uninterruptible (except -9) with a couple of zombie
    children left over".
    
    Reported-by: Andreas Schwab <schwab@suse.de>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
    Message-ID: <20260202091753.28459-1-pbonzini@redhat.com>
    (cherry picked from commit 251a3d4ca3c961d95cd624252a178a33066455a2)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 1af52156676065b1fc2d4815bf23b1c4c99938b3
Author: Aleksandr Sergeev <sergeev0xef@gmail.com>
Date:   Mon Jan 26 18:16:12 2026 +0300

    linux-user/syscall.c: Prevent acquiring clone_lock while fork()
    
    By the spec, fork() copies only the thread which executes it.
    So it may happen, what while one thread is doing a fork,
    another thread is holding `clone_lock` mutex
    (e.g. doing a `fork()` or `exit()`).
    So the child process is born with the mutex being held,
    and there are nobody to release it.
    
    As the thread executing do_syscall() is not considered running,
    start_exclusive() does not protect us from the case.
    
    Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3226
    Signed-off-by: Aleksandr Sergeev <sergeev0xef@gmail.com>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
    Message-ID: <20260126151612.2176451-1-sergeev0xef@gmail.com>
    (cherry picked from commit d22e9aec572396836782e993cb18d598e6012688)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit ba31a6fca7b03fce47228423b4dc951e04efd96c
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Fri Jan 2 15:47:31 2026 +0000

    hw/cxl: Take into account how many media operations are requested for param check
    
    Whilst the spec doesn't speak to it directly my assumption is that
    a request for more operations than exist should result in an invalid
    input error return.
    
    Fixes: 77a8e9fe0ecb ("hw/cxl/cxl-mailbox-utils: Add support for Media operations discovery commands cxl r3.2 (8.2.10.9.5.3)")
    Closes: https://lore.kernel.org/qemu-devel/CAFEAcA-p5wZkNxK7wNVq_3PAzEE-muOd1Def-0O-FSpck4DrBQ@mail.gmail.com/
    Reported-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260102154731.474859-3-Jonathan.Cameron@huawei.com>
    (cherry picked from commit 25465c0e1fd74d2118dfec03912f2595eeb497d7)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit fd0abbb38661a25af64649f9bf1f0f834943e203
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Fri Jan 2 15:47:30 2026 +0000

    hw/cxl: Check for overflow on santize media as both base and offset 64bit.
    
    The both the size and base of a media sanitize operation are both provided
    by the VM, an overflow is possible which may result in checks on valid
    range passing when they should not.  Close that by checking for overflow
    on the addition.
    
    Fixes: 40ab4ed10775 ("hw/cxl/cxl-mailbox-utils: Media operations Sanitize and Write Zeros commands CXL r3.2(8.2.10.9.5.3)")
    Closes: https://lore.kernel.org/qemu-devel/CAFEAcA8Rqop+ju0fuxN+0T57NBG+bep80z45f6pY0ci2fz_G3A@mail.gmail.com/
    Reported-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260102154731.474859-2-Jonathan.Cameron@huawei.com>
    (cherry picked from commit 87f8e5a71d061964c9bfa4d6e02db47f54dd61f7)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit e5628119e117b0dd6b14e6c398b219c5113a0970
Author: Honglei Huang <honghuan@amd.com>
Date:   Tue Jan 13 09:52:02 2026 +0800

    virtio-gpu: fix error handling in virgl_cmd_resource_create_blob
    
    Fix inverted error check in virgl_cmd_resource_create_blob() that causes
    the function to return error when virtio_gpu_create_mapping_iov() succeeds.
    
    virtio_gpu_create_mapping_iov() returns 0 on success and negative values
    on error. The check 'if (!ret)' incorrectly treats success (ret=0) as an
    error condition, causing the function to fail when it should succeed.
    
    Change the condition to 'if (ret != 0)' to properly detect errors.
    
    Fixes: 7c092f17ccee ("virtio-gpu: Handle resource blob commands")
    Signed-off-by: Honglei Huang <honghuan@amd.com>
    Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
    Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260113015203.3643608-2-honghuan@amd.com>
    (cherry picked from commit 3560b51979577afc3ab937fd8b02597515bdfbae)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit cfc706b38e2276afa9ee10645f849b3f43cc4997
Author: Li Chen <chenl311@chinatelecom.cn>
Date:   Tue Jan 6 16:38:59 2026 +0800

    virtio-pmem: ignore empty queue notifications
    
    virtio_pmem_flush() treats a NULL return from virtqueue_pop() as a fatal
    error and calls virtio_error(), which puts the device into NEEDS_RESET.
    
    However, virtqueue handlers can be invoked when no element is available,
    so an empty queue should be handled as a benign no-op.
    
    With a Linux guest this avoids spurious NEEDS_RESET and the resulting
    -EIO propagation (e.g. EXT4 journal abort and remount-ro).
    
    Signed-off-by: Li Chen <me@linux.beauty>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260106083859.380338-1-me@linux.beauty>
    (cherry picked from commit efd581a8cd4405ca183ecd017072b0c878802d69)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit be88ad424c0bbdab8746d4c99ebc7e15fbab1533
Author: Joelle van Dyne <j@getutm.app>
Date:   Sat Jan 3 13:43:59 2026 -0800

    virtio-gpu-virgl: correct parent for blob memory region
    
    When `owner` == `mr`, `object_unparent` will crash:
    
    object_unparent(mr) ->
    object_property_del_child(mr, mr) ->
    object_finalize_child_property(mr, name, mr) ->
    object_unref(mr) ->
    object_finalize(mr) ->
    object_property_del_all(mr) ->
    object_finalize_child_property(mr, name, mr) ->
    object_unref(mr) ->
    fail on g_assert(obj->ref > 0)
    
    However, passing a different `owner` to `memory_region_init` does not
    work. `memory_region_ref` has an optimization where it takes a ref
    only on the owner. That means when flatviews are created, it does not
    take a ref on the region and you can get a UAF from `flatview_destroy`
    called from RCU.
    
    The correct fix therefore is to use `NULL` as the name which will set
    the `owner` but not the `parent` (which is still NULL). This allows us
    to use `memory_region_ref` on itself while not having to rely on unparent
    for cleanup.
    
    Signed-off-by: Joelle van Dyne <j@getutm.app>
    Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20260103214400.71694-1-j@getutm.app>
    (cherry picked from commit e27194e087aede62dbe3d2805c6f1aa30d3465df)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 51514aa3c2f1e072c9728c975865e0b247b2619b
Author: zhenwei pi <pizhenwei@tensorfer.com>
Date:   Sun Dec 21 10:43:21 2025 +0800

    cryptodev-builtin: Limit the maximum size
    
    This backend driver is used for demonstration purposes only, unlimited
    size leads QEMU OOM.
    
    Fixes: CVE-2025-14876
    Fixes: 1653a5f3fc7 ("cryptodev: introduce a new cryptodev backend")
    Reported-by: 이재영 <nakamurajames123@gmail.com>
    Signed-off-by: zhenwei pi <zhenwei.pi@linux.dev>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20251221024321.143196-3-zhenwei.pi@linux.dev>
    (cherry picked from commit 7b913094c703641a0442bb1d1165323a019c591c)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

commit 2ac11c1d9370423ccdc527f9159ddd2ba4a2ea77
Author: zhenwei pi <pizhenwei@tensorfer.com>
Date:   Sun Dec 21 10:43:20 2025 +0800

    hw/virtio/virtio-crypto: verify asym request size
    
    The total lenght of request is limited by cryptodev config, verify it
    to avoid unexpected request from guest.
    
    Fixes: CVE-2025-14876
    Fixes: 0e660a6f90a ("crypto: Introduce RSA algorithm")
    Reported-by: 이재영 <nakamurajames123@gmail.com>
    Signed-off-by: zhenwei pi <zhenwei.pi@linux.dev>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Message-Id: <20251221024321.143196-2-zhenwei.pi@linux.dev>
    (cherry picked from commit 91c6438caffc880e999a7312825479685d659b44)
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Created: 2026-03-19 Last update: 2026-04-24 08:03

3 bugs tagged patch in the BTS normal

The BTS contains patches fixing 3 bugs, consider including or untagging them.

Created: 2026-04-06 Last update: 2026-04-24 08:00

lintian reports 58 warnings normal

Lintian reports 58 warnings about this package. You should make the package lintian clean getting rid of them.

Created: 2026-04-23 Last update: 2026-04-24 05:31

1 open merge request in Salsa normal

There is 1 open merge request for this package on Salsa. You should consider reviewing and/or merging these merge requests.

Created: 2025-11-25 Last update: 2026-01-14 16:48

18 low-priority security issues in bookworm low

There are 18 open security issues in bookworm.

18 issues left for the package maintainer to handle:

CVE-2021-3735: (postponed; to be fixed through a stable update) A deadlock issue was found in the AHCI controller device of QEMU. It occurs on a software reset (ahci_reset_port) while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.
CVE-2022-3872: (postponed; to be fixed through a stable update) An off-by-one read/write issue was found in the SDHCI device of QEMU. It occurs when reading/writing the Buffer Data Port Register in sdhci_read_dataport and sdhci_write_dataport, respectively, if data_count == block_size. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.
CVE-2023-1386: (postponed; to be fixed through a stable update) A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. When a local user in the guest writes an executable file with SUID or SGID, none of these privileged bits are correctly dropped. As a result, in rare circumstances, this flaw could be used by malicious users in the guest to elevate their privileges within the guest and help a host local user to elevate privileges on the host.
CVE-2024-6519: (needs triaging) A use-after-free vulnerability was found in the QEMU LSI53C895A SCSI Host Bus Adapter emulation. This issue can lead to a crash or VM escape.
CVE-2024-7730: (needs triaging) A heap buffer overflow was found in the virtio-snd device in QEMU. When reading input audio in the virtio-snd input callback, virtio_snd_pcm_in_cb, the function did not check whether the iov can fit the data buffer. This issue can trigger an out-of-bounds write if the size of the virtio queue element is equal to virtio_snd_pcm_status, which makes the available space for audio data zero.
CVE-2024-8354: (needs triaging) A flaw was found in QEMU. An assertion failure was present in the usb_ep_get() function in hw/net/core.c when trying to get the USB endpoint from a USB device. This flaw may allow a malicious unprivileged guest user to crash the QEMU process on the host and cause a denial of service condition.
CVE-2024-8612: (needs triaging) A flaw was found in QEMU, in the virtio-scsi, virtio-blk, and virtio-crypto devices. The size for virtqueue_push as set in virtio_scsi_complete_req / virtio_blk_req_complete / virito_crypto_req_complete could be larger than the true size of the data which has been sent to guest. Once virtqueue_push() finally calls dma_memory_unmap to ummap the in_iov, it may call the address_space_write function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.
CVE-2026-2243: (needs triaging) A flaw was found in QEMU. A specially crafted VMDK image could trigger an out-of-bounds read vulnerability, potentially leading to a 12-byte leak of sensitive information or a denial of service condition (DoS).
CVE-2026-3842: (needs triaging)
CVE-2026-3890: (needs triaging)
CVE-2026-5763: (needs triaging)
CVE-2019-12067: (postponed; to be fixed through a stable update) The ahci_commit_buf function in ide/ahci.c in QEMU allows attackers to cause a denial of service (NULL dereference) when the command header 'ad->cur_cmd' is null.
CVE-2020-25741: (postponed; to be fixed through a stable update) fdctrl_write_data in hw/block/fdc.c in QEMU 5.0.0 has a NULL pointer dereference via a NULL block pointer for the current drive.
CVE-2020-25742: (postponed; to be fixed through a stable update) pci_change_irq_level in hw/pci/pci.c in QEMU before 5.1.1 has a NULL pointer dereference because pci_get_bus() might not return a valid pointer.
CVE-2020-25743: (postponed; to be fixed through a stable update) hw/ide/pci.c in QEMU before 5.1.1 can trigger a NULL pointer dereference because it lacks a pointer check before an ide_cancel_dma_sync call.
CVE-2020-35503: (postponed; to be fixed through a stable update) A NULL pointer dereference flaw was found in the megasas-gen2 SCSI host bus adapter emulation of QEMU in versions before and including 6.0. This issue occurs in the megasas_command_cancelled() callback function while dropping a SCSI request. This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
CVE-2021-20255: (postponed; to be fixed through a stable update) A stack overflow via an infinite recursion vulnerability was found in the eepro100 i8255x device emulator of QEMU. This issue occurs while processing controller commands due to a DMA reentry issue. This flaw allows a guest user or process to consume CPU cycles or crash the QEMU process on the host, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
CVE-2025-14876: (needs triaging) A flaw was found in the virtio-crypto device of QEMU. A malicious guest operating system can exploit a missing length limit in the AKCIPHER path, leading to uncontrolled memory allocation. This can result in a denial of service (DoS) on the host system by causing the QEMU process to terminate unexpectedly.

You can find information about how to handle these issues in the security team's documentation.

Created: 2023-06-10 Last update: 2026-04-23 17:30

debian/patches: 7 patches to forward upstream low

Among the 22 debian patches available in version 1:11.0.0+ds-1 of the package, we noticed the following issues:

7 patches where the metadata indicates that the patch has not yet been forwarded upstream. You should either forward the patch upstream or update the metadata to document its real status.

Created: 2023-02-26 Last update: 2026-04-23 06:02

Standards version of the package is outdated. wishlist

The package should be updated to follow the last version of Debian Policy (Standards-Version 4.7.4 instead of 4.7.2).

Created: 2025-12-23 Last update: 2026-04-23 00:19

testing migrations

excuses:
- Migrates after: glibc, zlib
- Migration status for qemu (1:10.2.2+ds-1 to 1:11.0.0+ds-1): BLOCKED: Rejected/violates migration policy/introduces a regression
- Issues preventing migration:
- ∙ ∙ removing qemu-system/1:10.2.2+ds-1/armhf from testing makes libvirt-daemon-driver-qemu/12.0.0-1/armhf uninstallable
- ∙ ∙ removing qemu-system/1:10.2.2+ds-1/armhf from testing makes qemubuilder/0.90/armhf uninstallable
- ∙ ∙ removing qemu-system-arm/1:10.2.2+ds-1/armhf from testing makes dracut-test/110-12/armhf uninstallable
- ∙ ∙ removing qemu-system-x86/1:10.2.2+ds-1/armhf from testing makes os-autoinst/5.1775744546.1ee50c6b-3/armhf uninstallable
- ∙ ∙ removing qemu-system-x86/1:10.2.2+ds-1/armhf from testing makes quickemu/4.9.7-4/armhf uninstallable
- ∙ ∙ removing qemu-system/1:10.2.2+ds-1/i386 from testing makes libvirt-daemon-driver-qemu/12.0.0-1/i386 uninstallable
- ∙ ∙ removing qemu-system/1:10.2.2+ds-1/i386 from testing makes qemubuilder/0.90/i386 uninstallable
- ∙ ∙ removing qemu-system-x86/1:10.2.2+ds-1/i386 from testing makes os-autoinst/5.1775744546.1ee50c6b-3/i386 uninstallable
- ∙ ∙ removing qemu-system-x86/1:10.2.2+ds-1/i386 from testing makes quickemu/4.9.7-4/i386 uninstallable
- ∙ ∙ Autopkgtest for debusine/0.14.5: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for dracut/110-12: amd64: Pass, arm64: Pass, i386: No tests, superficial or marked flaky ♻, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for libvirt/12.0.0-1: amd64: Pass, arm64: Pass, i386: Test deferred, ppc64el: Pass, riscv64: Pass, s390x: Pass
- ∙ ∙ Autopkgtest for nova/2:33.0.0-4: amd64: Pass, arm64: Regression ♻ (reference ♻), i386: No tests, superficial or marked flaky ♻ (reference ♻), ppc64el: Pass, riscv64: No tests, superficial or marked flaky ♻, s390x: No tests, superficial or marked flaky ♻
- ∙ ∙ Autopkgtest for qemu/1:11.0.0+ds-1: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: Pass
- ∙ ∙ Too young, only 1 of 5 days old
- ∙ ∙ Built-Using: qemu glibc (not considered)
- ∙ ∙ Built-Using: qemu zlib (not considered)
- Additional info (not blocking):
- ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/q/qemu.html
- ∙ ∙ Reproducibility regression on amd64: qemu-block-extra, qemu-guest-agent, qemu-system, qemu-system-common, qemu-system-gui, qemu-system-modules-opengl, qemu-system-modules-spice, qemu-system-s390x, qemu-system-x86, qemu-system-xen, qemu-user-binfmt, qemu-utils
- ∙ ∙ Not reproduced on arm64 (not a regression): qemu-system-arm, qemu-system-data, qemu-system-mips, qemu-system-misc, qemu-system-ppc, qemu-system-riscv, qemu-system-sparc, qemu-user
- ∙ ∙ Not reproduced on armhf (not a regression): qemu-system-data
- ∙ ∙ Not reproduced on i386 (not a regression): qemu-system-data
- ∙ ∙ Reproducibility check waiting for results on ppc64el
- Not considered

news

[rss feed]

[2026-04-22] Accepted qemu 1:11.0.0+ds-1 (source) into unstable (Michael Tokarev)
[2026-04-11] Accepted qemu 1:11.0.0~rc3+ds-1 (source) into experimental (Michael Tokarev)
[2026-04-06] qemu 1:10.2.2+ds-1 MIGRATED to testing (Debian testing watch)
[2026-04-03] Accepted qemu 1:11.0.0~rc2+ds-2 (source) into experimental (Michael Tokarev)
[2026-04-03] Accepted qemu 1:11.0.0~rc2+ds-1 (source) into experimental (Michael Tokarev)
[2026-03-26] Accepted qemu 1:11.0.0~rc1+ds-3 (source) into experimental (Michael Tokarev)
[2026-03-25] Accepted qemu 1:11.0.0~rc1+ds-2 (source) into experimental (Michael Tokarev)
[2026-03-24] Accepted qemu 1:11.0.0~rc1+ds-1 (source) into experimental (Michael Tokarev)
[2026-03-19] Accepted qemu 1:10.2.2+ds-1 (source) into unstable (Michael Tokarev)
[2026-03-19] Accepted qemu 1:11.0.0~rc0+ds-2 (source) into experimental (Michael Tokarev)
[2026-03-19] Accepted qemu 1:11.0.0~rc0+ds-1 (source) into experimental (Michael Tokarev)
[2026-03-07] Accepted qemu 1:10.0.8+ds-0+deb13u1 (source) into proposed-updates (Debian FTP Masters) (signed by: Michael Tokarev)
[2026-02-24] qemu 1:10.2.1+ds-1 MIGRATED to testing (Debian testing watch)
[2026-02-13] Accepted qemu 1:10.2.1+ds-1 (source) into unstable (Michael Tokarev)
[2026-01-18] qemu 1:10.2.0+ds-2 MIGRATED to testing (Debian testing watch)
[2026-01-14] Accepted qemu 1:10.2.0+ds-2 (source) into unstable (Michael Tokarev)
[2026-01-01] Accepted qemu 1:7.2+dfsg-7+deb12u18 (source) into oldstable-proposed-updates (Debian FTP Masters) (signed by: Michael Tokarev)
[2026-01-01] Accepted qemu 1:10.0.7+ds-0+deb13u1 (source) into proposed-updates (Debian FTP Masters) (signed by: Michael Tokarev)
[2025-12-24] Accepted qemu 1:10.2.0+ds-1 (source) into unstable (Michael Tokarev)
[2025-12-15] Accepted qemu 1:10.1.3+ds-1 (source) into unstable (Michael Tokarev)
[2025-12-14] qemu 1:10.1.2+ds-3 MIGRATED to testing (Debian testing watch)
[2025-12-07] Accepted qemu 1:7.2+dfsg-7+deb12u17 (source) into oldstable-proposed-updates (Debian FTP Masters) (signed by: Michael Tokarev)
[2025-11-19] Accepted qemu 1:10.2.0~rc1+ds-1 (source) into experimental (Michael Tokarev)
[2025-11-13] Accepted qemu 1:10.1.2+ds-3 (source) into unstable (Michael Tokarev)
[2025-11-05] Accepted qemu 1:10.0.6+ds-0+deb13u2 (source) into proposed-updates (Debian FTP Masters) (signed by: Michael Tokarev)
[2025-11-04] Accepted qemu 1:10.1.2+ds-2 (source) into unstable (Michael Tokarev)
[2025-10-31] Accepted qemu 1:10.0.6+ds-0+deb13u1 (source) into proposed-updates (Debian FTP Masters) (signed by: Michael Tokarev)
[2025-10-25] qemu 1:10.1.2+ds-1 MIGRATED to testing (Debian testing watch)
[2025-10-21] Accepted qemu 1:10.1.2+ds-1 (source) into unstable (Michael Tokarev)
[2025-10-13] qemu 1:10.1.1+ds-1 MIGRATED to testing (Debian testing watch)

bugs [bug history graph]

all: 112 121
RC: 0
I&N: 49
M&W: 63 72
F&P: 0
patch: 3

links

homepage
lintian (0, 58)
buildd: logs, reproducibility
popcon
browse source code
other distros
security tracker
l10n (-, 94)
debian patches
debci

ubuntu

[Information about Ubuntu for Debian Developers]

version: 1:10.2.1+ds-1ubuntu3
91 bugs (2 patches)