Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: cfda94eddb6c9c49b66461c950b22845a46a75c9
https://github.com/qemu/qemu/commit/cfda94eddb6c9c49b66461c950b22845a46a75c9
Author: Halil Oktay (oblivionsage) <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M block/vmdk.c
Log Message:
-----------
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) <[email protected]>
Signed-off-by: Halil Oktay (oblivionsage) <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: d57bdcae9a8a90b3e1ffb4d5b5ee2909ce5416c2
https://github.com/qemu/qemu/commit/d57bdcae9a8a90b3e1ffb4d5b5ee2909ce5416c2
Author: Peter Krempa <[email protected]>
Date: 2026-03-04 (Wed, 04 Mar 2026)
Changed paths:
M block/monitor/block-hmp-cmds.c
M block/qapi.c
M qapi/block-core.json
M ui/cocoa.m
Log Message:
-----------
block: Wire up 'flat' mode also for 'query-block'
Some time ago (commit facda5443f5a8) I've added 'flat' mode (which
omits 'backing-image' key in reply) to 'query-named-block-nodes' to
minimize the size of the returned JSON for deeper backing chains.
While 'query-block' behaved slightly better it turns out that in libvirt
we do call 'query-block' to figure out some information about the
block device (e.g. throttling info) but we don't look at the backing
chain itself.
Wire up 'flat' for 'query-block' so that libvirt can ask for an
abbreviated output. The implementation is much simpler as the internals
are shared with 'query-named-block-nodes'.
Signed-off-by: Peter Krempa <[email protected]>
Acked-by: Markus Armbruster <[email protected]>
Message-ID:
<f4476e9f7e8fda74c02be3f806acaa9aa2df4d9a.1770210044.git.pkre...@redhat.com>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: b2e9401cc9cec714b545bd1a5d56bc3ef4c4c6e2
https://github.com/qemu/qemu/commit/b2e9401cc9cec714b545bd1a5d56bc3ef4c4c6e2
Author: Peter Krempa <[email protected]>
Date: 2026-03-04 (Wed, 04 Mar 2026)
Changed paths:
M block/monitor/block-hmp-cmds.c
Log Message:
-----------
hmp_nbd_server_start: Don't ask for backing image data
'hmp_nbd_server_start' uses only the device name from the data returned
from 'qmp_query_block', thus no backing file information. Use the new
options to suppress asking for the unused parts to save on resources.
Signed-off-by: Peter Krempa <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Message-ID:
<df71ca72a96d870758695ac57772fcfb87dc8fa0.1770210044.git.pkre...@redhat.com>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 6f7b0a23a6ea0cc72ad222ab37936248d99d4256
https://github.com/qemu/qemu/commit/6f7b0a23a6ea0cc72ad222ab37936248d99d4256
Author: Antoine Damhet <[email protected]>
Date: 2026-03-04 (Wed, 04 Mar 2026)
Changed paths:
M block/curl.c
Log Message:
-----------
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: [email protected]
Signed-off-by: Antoine Damhet <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 0f51f9c3420b31bb383e456dd7bf24d3056eeb73
https://github.com/qemu/qemu/commit/0f51f9c3420b31bb383e456dd7bf24d3056eeb73
Author: Kevin Wolf <[email protected]>
Date: 2026-03-04 (Wed, 04 Mar 2026)
Changed paths:
M block/mirror.c
Log Message:
-----------
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: [email protected]
Closes: https://gitlab.com/qemu-project/qemu/-/issues/3273
Fixes: 32125b14606a ('mirror: Fix access of uninitialised fields during start')
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Fiona Ebner <[email protected]>
Tested-by: Jean-Louis Dupond <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: d4816177654d59e26ce212c436513f01842eb410
https://github.com/qemu/qemu/commit/d4816177654d59e26ce212c436513f01842eb410
Author: Dmitry Guryanov <[email protected]>
Date: 2026-03-06 (Fri, 06 Mar 2026)
Changed paths:
M block/throttle-groups.c
M include/block/throttle-groups.h
Log Message:
-----------
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 <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Hanna Czenczek <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 544ddbb6373d61292a0e2dc269809cd6bd5edec6
https://github.com/qemu/qemu/commit/544ddbb6373d61292a0e2dc269809cd6bd5edec6
Author: Kevin Wolf <[email protected]>
Date: 2026-03-06 (Fri, 06 Mar 2026)
Changed paths:
M monitor/monitor.c
M qapi/block-core.json
Log Message:
-----------
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 <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 1d6610099bd7fc159626a38e60a3c84343ff67f7
https://github.com/qemu/qemu/commit/1d6610099bd7fc159626a38e60a3c84343ff67f7
Author: Hanna Czenczek <[email protected]>
Date: 2026-03-06 (Fri, 06 Mar 2026)
Changed paths:
M block/nfs.c
Log Message:
-----------
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: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 910451bc5b08b45863e173b58cbf2288b82d9fd2
https://github.com/qemu/qemu/commit/910451bc5b08b45863e173b58cbf2288b82d9fd2
Author: Hanna Czenczek <[email protected]>
Date: 2026-03-06 (Fri, 06 Mar 2026)
Changed paths:
M block/qcow2.c
M include/block/block_int-common.h
M tests/qemu-iotests/082.out
Log Message:
-----------
qcow2: Add keep_data_file command-line option
Add a command-line-only option to prevent overwriting the file specified
as external data file.
This option is only available on the qemu-img create command line, not
via blockdev-create, as it makes no sense there: That interface
separates file creation and formatting, so where the external data file
attached to a newly formatted qcow2 node comes from is completely up to
the user.
Implementation detail: Enabling this option will not only not overwrite
the external data file, but also assume it already exists, for two
reasons:
- It is simpler than checking whether the file exists, and only skipping
creating it when it does not. It is therefore also less error-prone,
i.e. we can never accidentally overwrite an existing file because we
made some mistake in checking whether it exists.
- I think it makes sense from a user's perspective: You set this option
when you want to use an existing data file, and you unset it when you
want a new one. Getting an error when you expect to use an existing
data file seems to me a nice warning that something is not right.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
[kwolf: Removed redundant has_data_file_raw check]
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 695d481a12a1190e1dd71761f0393047f6e16932
https://github.com/qemu/qemu/commit/695d481a12a1190e1dd71761f0393047f6e16932
Author: Hanna Czenczek <[email protected]>
Date: 2026-03-06 (Fri, 06 Mar 2026)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Simplify size round-up in co_create_opts
Use the now-existing qcow2_opts pointer to simplify the size rounding up
code.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 21b4e03b7d2f12ec269168380fe1f99afeda3835
https://github.com/qemu/qemu/commit/21b4e03b7d2f12ec269168380fe1f99afeda3835
Author: Hanna Czenczek <[email protected]>
Date: 2026-03-06 (Fri, 06 Mar 2026)
Changed paths:
M tests/qemu-iotests/common.filter
Log Message:
-----------
iotests/common.filter: Sort keep_data_file
Sort the new keep_data_file creation option together with data_file and
data_file_raw.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: a844ad5da2d0d16bab819c6b50c9cba0012ed202
https://github.com/qemu/qemu/commit/a844ad5da2d0d16bab819c6b50c9cba0012ed202
Author: Hanna Czenczek <[email protected]>
Date: 2026-03-06 (Fri, 06 Mar 2026)
Changed paths:
M tests/qemu-iotests/244
M tests/qemu-iotests/244.out
Log Message:
-----------
iotests/244: Add test cases for keep_data_file
Add various test cases around keep_data_file to the existing data_file
test suite 244.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
[kwolf: Added prealloc=full to the test]
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: d41b9b44ac9a9c4d82cc74f59bfd1bdd4ac4014c
https://github.com/qemu/qemu/commit/d41b9b44ac9a9c4d82cc74f59bfd1bdd4ac4014c
Author: Peter Maydell <[email protected]>
Date: 2026-03-06 (Fri, 06 Mar 2026)
Changed paths:
M block/curl.c
M block/mirror.c
M block/monitor/block-hmp-cmds.c
M block/nfs.c
M block/qapi.c
M block/qcow2.c
M block/throttle-groups.c
M block/vmdk.c
M include/block/block_int-common.h
M include/block/throttle-groups.h
M monitor/monitor.c
M qapi/block-core.json
M tests/qemu-iotests/082.out
M tests/qemu-iotests/244
M tests/qemu-iotests/244.out
M tests/qemu-iotests/common.filter
M ui/cocoa.m
Log Message:
-----------
Merge tag 'for-upstream' of https://gitlab.com/kmwolf/qemu into staging
Block layer patches
- Wire up 'flat' mode also for 'query-block'
- Never drop BLOCK_IO_ERROR with action=stop for rate limiting
- qcow2: Add keep_data_file command-line option
- vmdk: fix OOB read in vmdk_read_extent()
- curl: fix concurrent completion handling
- nfs: Fix deadlock
- mirror: Fix missed dirty bitmap writes during startup
- throttle-groups: fix deadlock with iolimits and muliple iothreads
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmmrHbgRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9b+ng/+P4B3q+Rrvb5WWrY8fro/3kzSqGAHjKeL
# QqEU8zywck5EorzK0H2f8BskxqXJ/LAe7ut4rFGqCA85l/eyWT7OhGm/DHnO/oI8
# /nU5r800/ZpvKn9HqK5+TSkswYQ6RmmMF9ZYIfYdB/JqPAmVmvbcjdqASVRT4PZ+
# v9QUKY309LDoaWm+vO/f0oPyxhog6yDHVh/rGhDkCOMyNExFyvfvAeLVuu+99Nzz
# GFxleM7JyHdVmIErbKRNp2Z/uVSQvlOg5uecI3IZnc2QUbACQWWc97PCP199JzZ+
# HaEq8tP+/TQZSsXEYKHmxYx4AyzCIu15qDmpnfhnoA9MC80P+eLrHJ5sXOsT6S32
# AyTLIE6KKLImtLyG6TZV05G127c7ekrMbY8OfY21ocACUstr4q6MY1J6ZCcLQRMZ
# E0BZR0CEOYtImrx0wr1XR0/q7SceiIaDcwFuPkHKz2akRS7bq9KH1RfxHYPpBJiX
# nkkLtilV4s/OlhrsoGJeq44C7jZA2MdrgouxNiPe+08CFeJra5wQybC7ZIYqknx6
# D/Eu4Y6KwMbyfnMd/4F0kbzHv9h8R+ri2hHUqfKEtl2pNTqe8JEpsPmn+yMpuRe4
# Cl66DFs0OzcONiUBNJVdGg0dm0jtIyCEo2am1MAJUgGkwYKxtgUQLsouSJS1d4EP
# iDe9pZmlytg=
# =kPKk
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri Mar 6 18:32:24 2026 GMT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "[email protected]"
# gpg: Good signature from "Kevin Wolf <[email protected]>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* tag 'for-upstream' of https://gitlab.com/kmwolf/qemu:
iotests/244: Add test cases for keep_data_file
iotests/common.filter: Sort keep_data_file
qcow2: Simplify size round-up in co_create_opts
qcow2: Add keep_data_file command-line option
block/nfs: Do not enter coroutine from CB
block: Never drop BLOCK_IO_ERROR with action=stop for rate limiting
block/throttle-groups: fix deadlock with iolimits and muliple iothreads
mirror: Fix missed dirty bitmap writes during startup
block/curl: fix concurrent completion handling
hmp_nbd_server_start: Don't ask for backing image data
block: Wire up 'flat' mode also for 'query-block'
block/vmdk: fix OOB read in vmdk_read_extent()
Signed-off-by: Peter Maydell <[email protected]>
Compare: https://github.com/qemu/qemu/compare/900682c57287...d41b9b44ac9a
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
