Branch: refs/heads/staging-10.1
Home: https://github.com/qemu/qemu
Commit: 46853d7d3ac6cde4f3e3857205d3ebc277221c76
https://github.com/qemu/qemu/commit/46853d7d3ac6cde4f3e3857205d3ebc277221c76
Author: Akihiko Odaki <[email protected]>
Date: 2026-02-03 (Tue, 03 Feb 2026)
Changed paths:
M hw/nvme/ns.c
M hw/nvme/nvme.h
Log Message:
-----------
hw/nvme: Fix bootindex suffix use-after-free
The bootindex suffix can be used as long as the property is alive.
Signed-off-by: Akihiko Odaki <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit eda9baa17a2854494709a8094419ba6a6901721d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d7500e12593a618612f365ad0f66440edab760cd
https://github.com/qemu/qemu/commit/d7500e12593a618612f365ad0f66440edab760cd
Author: Gerd Hoffmann <[email protected]>
Date: 2026-02-04 (Wed, 04 Feb 2026)
Changed paths:
M hw/uefi/var-service-vars.c
Log Message:
-----------
hw/uefi: fix size negotiation
Payload size is the variable request size, not the total buffer size.
Take that into account and subtract header sizes.
Fixes: db1ecfb473ac ("hw/uefi: add var-service-vars.c")
Signed-off-by: Gerd Hoffmann <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 46dee71a945d50639586ca3365be29aa9f368bfd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4bad6c7c9e63d17f41c3c173498e7f1a0f94c02f
https://github.com/qemu/qemu/commit/4bad6c7c9e63d17f41c3c173498e7f1a0f94c02f
Author: Cédric Le Goater <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/adc/aspeed_adc.c
Log Message:
-----------
hw/adc: Fix out-of-bounds write in Aspeed ADC model
The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
function has an out-of-bounds write vulnerability when accessing
unimplemented registers.
Fix this by using 'return' instead of 'break' in the default case,
which prevents execution from reaching the s->regs[reg] assignment for
unimplemented registers.
Reported-by: Elhrj Saad <[email protected]>
Fixes: 5857974d5d11 ("hw/adc: Add basic Aspeed ADC model")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 4c6521296d2b6820ab1f8c59d3a80cd0c138b2d8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2cf4cbc0118c84fa87a562edb6af7df9baef6198
https://github.com/qemu/qemu/commit/2cf4cbc0118c84fa87a562edb6af7df9baef6198
Author: Nabih Estefan <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/i2c/aspeed_i2c.c
Log Message:
-----------
hw/i2c/aspeed_i2c.c: Add a check for dma_read
If aspeed_i2c_dma_read fails in aspeed_i2c_bus_send currently, we get
stuck in an infinite retry loop. Add a check for the return value of
aspeed_i2c_dma_read that will break us out of said loop.
Signed-off-by: Nabih Estefan <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Fixes: 545d6bef7097 ("aspeed/i2c: Add support for DMA transfers")
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 0a1d4770670297a1da52118f84812e4a5ffc7722)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1b107b64b8372a0385c686cb7132676a9d899cbc
https://github.com/qemu/qemu/commit/1b107b64b8372a0385c686cb7132676a9d899cbc
Author: Jamin Lin <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/arm/aspeed_ast27x0.c
Log Message:
-----------
hw/arm/aspeed_ast27x0: Fix EHCI3/4 IRQ routing to GIC
EHCI3 and EHCI4 were missing entries in aspeed_soc_ast2700a1_irqmap,
so their source IRQs were never routed through the INTC OR-gates.
As a result, EHCI3/4 interrupts were not propagated to the GIC,
causing incorrect interrupt behavior for these controllers.
Add EHCI3 and EHCI4 to the IRQ map and route them to the same INTC
group as other shared peripherals, ensuring their interrupts are
properly connected to the GIC.
Signed-off-by: Jamin Lin <[email protected]>
Fixes: ba27ba302a264117c8b8427f944ced1bed17c438 ("hw/arm: ast27x0: Wire up EHCI
controllers")
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 7d64f04863ed23f6a142fb8f47c5a470c0e081f9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6af4aff2053ec98bfd54ace5973ff70f02c21a3e
https://github.com/qemu/qemu/commit/6af4aff2053ec98bfd54ace5973ff70f02c21a3e
Author: Jamin Lin <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/i2c/aspeed_i2c.c
Log Message:
-----------
hw/i2c/aspeed: Fix wrong I2CC_DMA_LEN when I2CM_DMA_TX/RX_ADDR set first
In the previous design, the I2C model would update I2CC_DMA_LEN (0x54) based on
the value of I2CM_DMA_LEN (0x1C) when the firmware set either I2CM_DMA_TX_ADDR
(0x30) or I2CM_DMA_RX_ADDR (0x34). However, this only worked correctly if the
firmware set I2CM_DMA_LEN before setting I2CM_DMA_TX_ADDR or I2CM_DMA_RX_ADDR.
If the firmware instead set I2CM_DMA_TX_ADDR or I2CM_DMA_RX_ADDR before setting
I2CM_DMA_LEN, the value written to I2CC_DMA_LEN would be incorrect.
To fix this issue, the model should be updated to set I2CC_DMA_LEN when the
firmware writes to the I2CM_DMA_LEN register, rather than when it writes to the
I2CM_DMA_RX_ADDR and I2CM_DMA_TX_ADDR registers.
Signed-off-by: Jamin Lin <[email protected]>
Fixes: ba2cccd64e90 ("aspeed: i2c: Add new mode support")
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 9cbd8ee7f67fceee51d3c993a282e5adc397b6b9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ea4be299f0184cfab7dee146fd1aa3c6a49947ae
https://github.com/qemu/qemu/commit/ea4be299f0184cfab7dee146fd1aa3c6a49947ae
Author: Jamin Lin <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/i2c/aspeed_i2c.c
Log Message:
-----------
hw/i2c/aspeed_i2c: Fix DMA moving data into incorrect address
In the previous design, the I2C model updated dma_dram_offset only when
firmware programmed the RX/TX DMA buffer address registers. The firmware
used to rewrite these registers before issuing each DMA command.
The firmware driver behavior has changed to program the DMA address
registers only once during I2C initialization. As a result, the I2C model
no longer refreshes dma_dram_offset, causing DMA to move data into an
incorrect DRAM address.
Fix this by introducing helper functions to update dma_dram_offset from
the DMA address registers, and invoke them right before handling TX/RX
DMA operations. This guarantees DMA always uses the correct buffer
address even if the registers are programmed only once.
Signed-off-by: Jamin Lin <[email protected]>
Fixes: c400c38854017eeccda63115814eba4c3ef2b51f ("hw/i2c/aspeed: Introduce a
new dma_dram_offset attribute in AspeedI2Cbus")
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit efea7ddb4689a1ac4bce63a9ddb32887c7f3ac50)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5e40faac9c83766b9833a9e8f2c437b0963f9882
https://github.com/qemu/qemu/commit/5e40faac9c83766b9833a9e8f2c437b0963f9882
Author: Wafer Xie <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/virtio/vhost-vdpa.c
M include/hw/virtio/vhost-vdpa.h
Log Message:
-----------
vdpa: fix vhost-vdpa suspended state not be shared
When stopping a vhost-vdpa device, only the first queue pair is marked as
suspended,
while the remaining queues are not updated to the suspended state.
As a result, when stopping a multi-queue vhost-vdpa device,
the following error message will be printed.
qemu-system-x86_64:vhost VQ 2 ring restore failed: -1: Operation not permitted
(1)
qemu-system-x86_64:vhost VQ 3 ring restore failed: -1: Operation not permitted
(1)
So move v->suspended to v->shared, and then all the vhost_vdpa devices cannot
have different suspended states.
Fixes: 0bb302a9960a ("vdpa: add vhost_vdpa_suspend")
Suggested-by: Eugenio Pérez <[email protected]>
Acked-by: Eugenio Pérez <[email protected]>
Acked-by: Jason Wang <[email protected]>
Signed-off-by: Wafer Xie <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Acked-by: Jason Wang <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit fd3a2c601ab4a1bdb669e4c584b364e00a978702)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 88d40c05782e0d7959048568f908b946418b407e
https://github.com/qemu/qemu/commit/88d40c05782e0d7959048568f908b946418b407e
Author: Dorinda Bassey <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/display/virtio-dmabuf.c
Log Message:
-----------
virtio-dmabuf: Ensure UUID persistence for hash table insertion
In `virtio_add_resource` function, the UUID used as a key for
`g_hash_table_insert` was temporary, which could lead to
invalid lookups when accessed later. This patch ensures that
the UUID remains valid by duplicating it into a newly allocated
memory space. The value is then inserted into the hash table
with this persistent UUID key to ensure that the key stored in
the hash table remains valid as long as the hash table entry
exists.
Fixes: faefdba847 ("hw/display: introduce virtio-dmabuf")
Signed-off-by: Dorinda Bassey <[email protected]>
Reviewed-by: Stefano Garzarella <[email protected]>
Reviewed-by: Albert Esteve <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Reviewed-by: Jim MacArthur <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit fff77cfb8413190c6362b95203ef0973c83b50d2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: dbb6465a08b665577ab849c462b553f98284da51
https://github.com/qemu/qemu/commit/dbb6465a08b665577ab849c462b553f98284da51
Author: Kevin Wolf <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/virtio/virtio-pci.c
Log Message:
-----------
virtio: Fix crash when sriov-pf is set for non-PCI-Express device
Setting the sriov-pf property on devices that aren't PCI Express causes
an assertion failure:
$ qemu-system-x86_64 \
-blockdev null-co,node-name=null \
-blockdev null-co,node-name=null2 \
-device virtio-blk,drive=null,id=pf \
-device virtio-blk,sriov-pf=pf,drive=null2
qemu-system-x86_64: ../hw/pci/pcie.c:1062: void
pcie_add_capability(PCIDevice *, uint16_t, uint8_t, uint16_t, uint16_t):
Assertion `offset >= PCI_CONFIG_SPACE_SIZE' failed.
This is because proxy->last_pcie_cap_offset is only initialised to a
non-zero value in virtio_pci_realize() if it's a PCI Express device, and
then virtio_pci_device_plugged() still tries to use it.
To fix this, just skip the SR-IOV code for !pci_is_express(). Then the
next thing pci_qdev_realize() does is call pcie_sriov_register_device(),
which returns the appropriate error.
Cc: [email protected]
Fixes: d0c280d3fac6 ('pcie_sriov: Make a PCI device with user-created VF
ARI-capable')
Signed-off-by: Kevin Wolf <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 623db856476806124e9ae45fbc39e75012261570)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0901e4379fb5a2a39688386c7983d98f94d01c27
https://github.com/qemu/qemu/commit/0901e4379fb5a2a39688386c7983d98f94d01c27
Author: Kevin Wolf <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/pci/pcie_sriov.c
Log Message:
-----------
pcie_sriov: Fix PCI_SRIOV_* accesses in pcie_sriov_pf_exit()
PCI_SRIOV_* are offsets into the SR-IOV capability, not into the PCI
config space. pcie_sriov_pf_exit() erroneously takes them as the latter,
which makes it read PCI_HEADER_TYPE and PCI_BIST when it tries to read
PCI_SRIOV_TOTAL_VF.
In many cases we're lucky enough that the PCI config space will be 0
there, so we just skip the whole for loop, but this isn't guaranteed.
For example, setting the multifunction bit on the PF and then doing a
'device_del' on it will get a larger number and cause a segfault.
Fix this and access the real PCI_SRIOV_* fields in the capability.
Cc: [email protected]
Fixes: 19e55471d4e8 ('pcie_sriov: Allow user to create SR-IOV device')
Signed-off-by: Kevin Wolf <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit f73e5ed9bc4cfacf041323a6b40a85e6b6459b75)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 259da6b08f7e4baf580e9d363fb72dfe2292784d
https://github.com/qemu/qemu/commit/259da6b08f7e4baf580e9d363fb72dfe2292784d
Author: Igor Mammedov <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/pci-host/q35.c
M tests/qtest/q35-test.c
Log Message:
-----------
q35: Fix migration of SMRAM state
When migrating, dst QEMU by default has SMRAM unlocked,
and since wmask is not migrated, the migrated value of
MCH_HOST_BRIDGE_F_SMBASE in config space fall to prey of
mch_update_smbase_smram()
...
if (pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] == 0xff) {
*reg = 0x00;
and is getting cleared and leads to unlocked smram
on dst even if on source it's been locked.
As Andrey has pointed out [1], we should derive wmask
from config and not other way around.
Drop offending chunk and resync wmask based on MCH_HOST_BRIDGE_F_SMBASE
register value. That would preserve the register during
migration and set smram regions into corresponding state.
What that changes is:
that it would let guest write junk values in register
(with no apparent effect) until it's stumbles upon
reserved 0x1 [|] 0x2 values, at which point it
would be only possible to lock register and trigger
switch to SMRAM blackhole in CPU AS.
While at it, fix up test by removing junk discard before negotiation hunk.
PS2:
Instead of adding a dedicated post_load handler for it,
reuse mch_update->mch_update_smbase_smram call chain
that is called on write/reset/post_load to be consistent
with how we handle mch registers.
PS3:
for prosterity here is erro message Andrey got due to this bug:
qemu: vfio_container_dma_map(0x..., 0x0, 0xa0000, 0x....) = -22 (Invalid
argument)
qemu: hardware error: vfio: DMA mapping failed, unable to continue
1) https://patchew.org/QEMU/[email protected]/
Fixes: f404220e279c ("q35: implement 128K SMRAM at default SMBASE address")
Reported-by: Andrey Ryabinin <[email protected]>
Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrey Ryabinin <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 66cf169e29b06dca104c5a229fba0da4ce33599c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1ea1baa5c89ec3158b198769e96128f9670bf981
https://github.com/qemu/qemu/commit/1ea1baa5c89ec3158b198769e96128f9670bf981
Author: zhenwei pi <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/virtio/virtio-crypto.c
Log Message:
-----------
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: 이재영 <[email protected]>
Signed-off-by: zhenwei pi <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 91c6438caffc880e999a7312825479685d659b44)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 95aac3231317b7d22af9eae803cd8b3977de8f6c
https://github.com/qemu/qemu/commit/95aac3231317b7d22af9eae803cd8b3977de8f6c
Author: zhenwei pi <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M backends/cryptodev-builtin.c
Log Message:
-----------
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: 이재영 <[email protected]>
Signed-off-by: zhenwei pi <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 7b913094c703641a0442bb1d1165323a019c591c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: da9b1cd37f66bf929bf65ec7a0982c5c6086ff71
https://github.com/qemu/qemu/commit/da9b1cd37f66bf929bf65ec7a0982c5c6086ff71
Author: Joelle van Dyne <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/display/virtio-gpu-virgl.c
Log Message:
-----------
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 <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit e27194e087aede62dbe3d2805c6f1aa30d3465df)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 21500ffad22101eab4e99058c371cddc55219d61
https://github.com/qemu/qemu/commit/21500ffad22101eab4e99058c371cddc55219d61
Author: Li Chen <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/virtio/virtio-pmem.c
Log Message:
-----------
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 <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit efd581a8cd4405ca183ecd017072b0c878802d69)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fc186fdb6a87f4f6e6394948c6af14452c866af4
https://github.com/qemu/qemu/commit/fc186fdb6a87f4f6e6394948c6af14452c866af4
Author: Honglei Huang <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/display/virtio-gpu-virgl.c
Log Message:
-----------
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 <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 3560b51979577afc3ab937fd8b02597515bdfbae)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 36c85f19e16238ec82c9034460c6cc714e9d1a8c
https://github.com/qemu/qemu/commit/36c85f19e16238ec82c9034460c6cc714e9d1a8c
Author: Jonathan Cameron <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/cxl/cxl-mailbox-utils.c
Log Message:
-----------
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_...@mail.gmail.com/
Reported-by: Peter Maydell <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 87f8e5a71d061964c9bfa4d6e02db47f54dd61f7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 25d3fa63679a2a4dd53adf98e83e3551826545d6
https://github.com/qemu/qemu/commit/25d3fa63679a2a4dd53adf98e83e3551826545d6
Author: Jonathan Cameron <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/cxl/cxl-mailbox-utils.c
Log Message:
-----------
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-fspck4d...@mail.gmail.com/
Reported-by: Peter Maydell <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 25465c0e1fd74d2118dfec03912f2595eeb497d7)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/de302beabe72...25d3fa63679a
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
