August 2026 - Devel - libvirt List Archives

[PATCH 0/2] Fix double free of stream error reply aborting libvirtd
by Ross Golder 27 Aug '26

27 Aug '26

libvirtd aborts with "free(): invalid pointer" whenever a stream write fails, and then crash-loops until systemd's start limit is reached, leaving the host with no management plane. Running guests are unaffected but become unmanageable. The cause is an ambiguous return contract. daemonStreamHandleWriteData() reports a failed stream write through virNetServerProgramSendReplyError(), which takes ownership of the message and queues it on client->tx, and then returns that function's result - 0 on success. Its caller reads 0 as "no reply was sent" and, for VIR_NET_CONTINUE, clears the message and queues it a second time. Since the message is by then the sole element of client->tx, virNetMessageQueuePush() walks to the tail - itself - and links it to itself. virNetMessageQueueServe() then hands out the same pointer twice and virNetServerClientDispatchWrite() frees it twice. Patch 1 is the fix: give the handlers a distinct return value meaning "already queued, do not touch msg again". daemonStreamHandleHole() had the same defect and is fixed alongside. Note the requeue test has to change from "ret > 0" to "ret == 1", otherwise the new value would requeue a message which is already on client->tx. Patch 2 is independent hardening: make virNetMessageQueuePush() refuse a push that would corrupt the list, so a caller bug of this shape surfaces as a log message rather than as heap corruption. It includes a regression test that reproduces the self-cycle deterministically. Note that virNetMessageClear() memsets the whole message including ->next, so a queued message can appear unlinked. That is why patch 2 walks the queue rather than testing msg->next, and why this class of bug is easy to miss by inspection. There is no ABI change; src/libvirt_remote.syms is untouched. Evidence -------- - valgrind memcheck: "Invalid free()" with the previous free at the *same* call site, plus 13 invalid reads and 6 invalid writes as the "while (client->tx)" loop re-reads the freed block. Exactly one invalid free per occurrence, as a self-cycle predicts. - A production core dump whose crash IP is the return address of the same call to virNetMessageFree(), resolving to virnetserverclient.c:1374. - Instrumented builds logging both push sites: virNetServerProgramSendError:168 followed by daemonStreamHandleWrite:797. Two cautions for anyone reproducing this: Under valgrind the daemon does *not* abort - memcheck replaces the allocator, so glibc's malloc_printerr never runs. It logs and continues, and the fault is easy to mistake for "works fine". Freed virNetMessage blocks are promptly reused by malloc, so the same address legitimately reappears as a new message moments after being freed. In RPC debug logs that closely resembles a use-after-free and is not one. Testing ------- Reproduced and fixed on three production hypervisors running 12.5.0 with these patches backported. One host had logged 5197 aborts beforehand; across all three there have been zero aborts and zero hardening warnings since. The hardening warning firing before the patch 1 fix and never firing after it is the direct evidence that the root cause, and not just the symptom, is addressed. Full test suite passes on master (306 ok, 1 expected fail, 0 failures). CI on a personal fork is green: 22 jobs passed, 0 failed, covering Fedora 43/44/rawhide, CentOS Stream 9/10, Ubuntu 24.04/26.04 (including clang), openSUSE Tumbleweed/Leap 16, Debian 13, armv7l and mingw32/64, plus check-dco and codestyle. Reported as https://gitlab.com/libvirt/libvirt/-/issues/902 Ross Golder (2): remote: don't queue the stream error reply twice rpc: refuse to queue a message that is already queued src/remote/remote_daemon_stream.c | 51 +++++++++++++----- src/rpc/virnetmessage.c | 43 +++++++++++++++ tests/virnetmessagetest.c | 87 +++++++++++++++++++++++++++++++ 3 files changed, 169 insertions(+), 12 deletions(-) -- 2.53.0

2 4

[PATCH] NEWS: Document features/improvements/bug fixes I've participated in
by Michal Privoznik 27 Aug '26

27 Aug '26

From: Michal Privoznik <mprivozn(a)redhat.com> There are some features/improvements/bug fixes I've either contributed or reviewed/merged. Document them for upcoming release. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 89e470e29d..acd4c78dbe 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -47,12 +47,31 @@ v12.7.0 (unreleased) <wwn>01000000efbeadde</wwn> </disk> + * Add guest device info to ``virDomainGetGuestInfo()`` + + QEMU guest agent has 'guest-get-devices` command, which returns information + on guest devices (driver name, version, release date, and so on). This is + now exposed via ``virDomainGetGuestInfo()`` API (accessible via ``guestinfo + --devices`` virsh command). + + * **Improvements** * **Bug fixes** * bhyve: fix domain API calls hanging after domain shutdown + * remote: Fix stale virStream status + + In a few cases it might happen that daemon held incorrect state of a + virStream leading to an infinite loop. This is now fixed. + + * esx: Don't crash when parsing unmounted datastore + + When libvirt constructs domain XML for an ESX domain it traverses through + all datastores to find which one stores disks for the domain. But if a + datastore wasn't mounted, then a crash would occur. This is now fixed. + v12.6.0 (2026-08-03) ==================== -- 2.54.0

2 1

[PATCH] NEWS: document added qemu poll-weigth support
by Boris Fiuczynski 27 Aug '26

27 Aug '26

Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 89e470e29d..bce158af0a 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -47,6 +47,12 @@ v12.7.0 (unreleased) <wwn>01000000efbeadde</wwn> </disk> + * qemu: Add poll-weight support for iothreads + + The qemu driver now supports the iothread poll-weight property, + which controls the weight of the most recent event interval in the + adaptive polling duration calculation. + * **Improvements** * **Bug fixes** -- 2.54.0

2 1

[PATCH] ci: Add job to check if all mentioned CVEs have corresponding git tags
by Peter Krempa 27 Aug '26

27 Aug '26

From: Peter Krempa <pkrempa(a)redhat.com> Introduce a job which will run with the scheduled libvirt pipeline runs which will check if all CVEs mentioned in the git commit messages, NEWS entries and for all libvirt security notices published at https://security.libvirt.org have corresponding git tags. Since git commit messages do sometimes mention CVE not related to libvirt, the '.cve_exceptions' file lists allows to add overrides. Since the upstream repository has signed tags, the tagging is done by Jirka, so it doesn't make sense to run this check inside the checkout or as a regular CI pipeline run, so it's implemented directly in the CI job rather than as a standalone tool. The job also creates an artifact containing all tagged CVEs in the repository. This can later be used e.g. to see which CVEs are missing a libvirt security notice. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- .cve_exceptions | 46 +++++++++++++++++++++++++++++++++++++++++++++ .gitlab-ci.yml | 50 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 96 insertions(+) create mode 100644 .cve_exceptions In order for this to pass the following CVEs need to be tagged (the order of the commit IDs is as 'git log' shows): commitlog CVE-2026-15268 f74495c7a157618e3df6fa61079678084c4cc685 CVE-2026-18917 5a62cbf2907d4590283597b46da9c0f41e7b4d4f CVE-2026-61477 3cfc77963b512d809348fca07f97fe924fac9a05 cb8974b923e3c40cde96f0c7bceaa638f7f9c72b 289ffa796d737a79a4c05d07232ebd75def9a12a d44836a1dc6771ac22f69755fc69bf730f0eec87 CVE-2026-61478 68da70aae766c6271b8d3b466374d3cc7d1a8afb CVE-2026-63622 801160fd414ca2cc402bc01ead09b7ed4c3b8f5b CVE-2026-63623 69335a484768d550854da1133d5490074695e825 News CVE-2021-4147 5c5df5310f72be4878a71ace47074c54e0d1a27d security.libvirt.org CVE-2009-0036 be33b189a5e579509b5025d72b7f283401ef9dc1 CVE-2010-2237 68719c4bddb85fbcc931a5b7d99ac7c8a0af09b0 CVE-2010-2239 187da82fea598aa017bdfc82a1622f9c8d75ee74 CVE-2016-10746 506e9d6c2d4baaf580d489fff0690c0ff2ff588f CVE-2019-20485 d61f95cf6a6fbd564e104c168d325581acd9cd8d 4cc90c2e62df653e909ad31fd810224bf8bcf913 d9605abed68af4b65c4e04386346a2fd372d7ab9 95f5ac9ae52455e9da47afc95fa31c9456ac27ae 1cb8bc52c1035573a0c1a87f724a6c7dfee82f12 0a9893121187c0c3f9807e9164366e1f6977619c a663a860819287e041c3de672aad1d8543098ecc e005c95f56fee9ed780be7f8db103d690bd34cbd CVE-2019-3840 7cfd1fbb1332ae5df678b9f41a62156cb2e88c73 CVE-2020-10703 dfff16a7c261f8d28e3abe60a47165f845fa952f CVE-2020-14301 a5b064bf4b17a9884d7d361733737fb614ad8979 CPU CVE (covered by LSNs) CVE-2017-5715 6d4a3cd42781babed7d29b061e220ebff24dd43e 6b7e7d1cc24a28a9f5ece8626f807189647d14b4 2e3b220a874e558e54678afd7cf49466fe605e09 30b381cfdd5e92e5afa6de09f0fe533353e71d07 203c92e9cc2db854199b39ef3ffcc10406d3c59e 7dd85ff62d7080b52d4d175f53ad5eb11cdcfb9c 7f83eefa9e6940c83579d31941efd07fab1b90c8 49bffcb3cc1850d332b9648c686a7be18de9e708 7bb4ce9761dfbd1620ddffb26fbd6f0ff1fedf3f b2042020c32b74069fa5365b5e966537aaba8cf6 24d504396c3c05eff87d29173a224e2faaeb2637 CVE-2018-3639 9267342206ce17f6933d57a3128cdc504d5945c9 1dbca2eccad58d91a5fd33962854f1a653638182 CVE-2019-11135 f411b7ef68221e82dec0129aaf2f2a26a8987504 07aaced4e6ea6db8b27f44636f51cafa6f1847a8 diff --git a/.cve_exceptions b/.cve_exceptions new file mode 100644 index 0000000000..335085e1bd --- /dev/null +++ b/.cve_exceptions @@ -0,0 +1,46 @@ +This file contains CVE IDs mentioned in either the commit log or the NEWS which +are not actually CVEs in libvirt and is used for the sanity check ensuring that +we have git tags for all CVE patches. + +This file can contain any other text explaining given CVE as it's filtered for +just CVE ids for matching. + +Commit messages mention the following non-libvirt CVEs: + + - CVE-2011-4127: Kernel privilege escalation via SG_IO + + Mentioned as justification to introduce new disk access mode 'lun' + + - CVE-2012-3386: GNU Automake granting world-writable permissions to extraction directory + + Mentioned as justification for fixing a syntax check failure. + + - CVE-2013-0242: Buffer overflow in glibc's regexec code + + gnulib update + + - CVE-2013-4288: race condition in polkit allowing bypass of restrictions + + The libvirt patch references the required pokit fix + + - CVE-2014-6458: unspecified vulnerability in Oracle Java + + mentioned by mistake, same CVE id from 2013 was intended + + - CVE-2022-24765: git for windows safe directory handling + + CI needed to adapt to this fix + +Libvirt adjecent CVEs: + - CVE-2020-15708: libvirtd.sock being configured as world-writable + + This was a packaging/deployment bug in Ubuntu 20.10 allowing anyone access + the system connection as they shipped default socket permissions. Libvirt + later changed the default to harden against this + +The following CVEs mentioned in our NEWS or commitlog are referencing CPU bugs +that libvirt covered but didn't publish a LSN for: + - CVE-2018-12126: Microarchitectural Store Buffer Data Sampling (MSBDS) + - CVE-2018-12127: Microarchitectural Fill Buffer Data Sampling (MFBDS) + - CVE-2018-12130: Microarchitectural Load Port Data Sampling (MLPDS) + - CVE-2019-11091: Microarchitectural Data Sampling Uncacheable Memory (MDSUM) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 04bfef8ed7..7121248f7b 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -173,3 +173,53 @@ coverity: - if: '$CI_PROJECT_NAMESPACE == $RUN_UPSTREAM_NAMESPACE && $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH' when: on_success - when: never + +# Check that we have CVE git tags for CVEs mentioned in commit messages and NEWS +# and expose the list of CVE tags +cve_tags: + image: $CI_REGISTRY/$RUN_UPSTREAM_NAMESPACE/libvirt/ci-$NAME:latest + variables: + NAME: almalinux-9 + GIT_STRATEGY: clone + GIT_DEPTH: "" + stage: sanity_checks + needs: + - job: x86_64-almalinux-9-container + optional: true + artifacts: false + rules: + - if: $CI_PIPELINE_SOURCE == "schedule" + when: always + - when: never + script: + # fetch list of git tags and exceptions + - git tag | grep -o 'CVE-[0-9]\+-[0-9]\+' > cve-tags + - grep -o 'CVE-[0-9]\+-[0-9]\+' .cve_exceptions > cve-allowed-exceptions + - sort -u cve-tags cve-allowed-exceptions > cve-allowed + # lookup CVE ids in 'git-log' + - git log | grep -o '[Cc][Vv][Ee]-[0-9]\+-[0-9]\+' | sort -u > cves-found-log + - comm -2 -3 cves-found-log cve-allowed > cves-missing-tags-log + # lookup CVE ids in 'NEWS.rst' + - grep -o '[Cc][Vv][Ee]-[0-9]\+-[0-9]\+' NEWS.rst | sort -u > cves-found-news + - comm -2 -3 cves-found-news cve-allowed > cves-missing-tags-news + # lookup CVE ids in index of security notices + - curl -fsSL https://security.libvirt.org/index.xml | grep -o 'CVE-[0-9]\+-[0-9]\+' | sort -u > cves-found-notices + - comm -2 -3 cves-found-notices cve-allowed > cves-missing-tags-notices + - if [ -s cves-missing-tags-log ] || [ -s cves-missing-tags-news ] || [ -s cves-missing-tags-notices ]; + then + echo "Following CVE's are either missing a git tag or an exception in '.cve_exceptions:"; + echo "Source 'git log'"; + cat cves-missing-tags-log; + echo "Source 'NEWS.rst'"; + cat cves-missing-tags-news; + echo "Source 'security.libvirt.org/index.xml'"; + cat cves-missing-tags-notices; + false; + fi + artifacts: + expose_as: 'CVE tags' + name: 'cve_tags' + when: always + expire_in: 30 days + paths: + - cve-tags -- 2.55.0

2 2

[PATCH] qemu: Fix crash in qemuProcessStop due to NULL eventThread
by Sahoo, Pritam Srichandan 26 Aug '26

26 Aug '26

Hi, The attached patch fixes a NULL pointer dereference crash in the QEMU driver that was observed . Issue: libvirtd crashes with SIGSEGV in virEventThreadStop(evt=0x0) during VM shutdown. The crash occurs in qemuProcessStop() when it is invoked from the QEMU monitor EOF event worker thread. Root Cause: There is a race condition when two threads enter qemuProcessStop() concurrently for the same domain: - Thread A (shutdown path) frees priv->eventThread via g_steal_pointer(). - Thread B (EOF event worker) passes the "if (priv->eventThread)" NULL check while the pointer is still valid, but the VM object is then unlocked before virEventThreadStop() is called. In that window, Thread A clears priv->eventThread, so by the time Thread B calls virEventThreadStop(priv->eventThread), the pointer is already NULL, causing the SIGSEGV. The existing "if (priv->eventThread)" guard is insufficient because the VM object lock is released between the check and the actual call to virEventThreadStop(). Crash backtrace: #0 virEventThreadStop (evt=0x0) #1 qemuProcessStop (reason=VIR_DOMAIN_SHUTOFF_SHUTDOWN, asyncJob=VIR_ASYNC_JOB_NONE) #2 processMonitorEOFEvent (driver=..., vm=...) #3 qemuProcessEventHandler (data=..., opaque=...) #4 virThreadPoolWorker (opaque=...) Fix: Take a GObject reference on priv->eventThread before unlocking the VM object, use the local reference for virEventThreadStop(), then release it with g_object_unref() afterwards. This ensures the pointer remains valid for virEventThreadStop() even if another thread clears priv->eventThread concurrently. The affected code is present in current master (introduced in commit 0888784f387, 2024-07-25): https://gitlab.com/libvirt/libvirt/-/commit/0888784f387 (https://gitlab.com/libvirt/libvirt/-/commit/0888784f387) The crash is not reproducible on demand due to the narrow timing window of the race, but it is deterministic once the window is hit — virEventThreadStop(evt=0x0) will always SIGSEGV. The fix has been build-tested. Thanks, Pritam Srichandan Sahoo

1 0

[PATCH] NEWS: document bhyve changes for 12.7.0
by Roman Bogorodskiy 25 Aug '26

25 Aug '26

Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- NEWS.rst | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index ae4d8c18a5..e098fc53f9 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,10 +17,42 @@ v12.7.0 (unreleased) * **New features** + * bhyve: implement ``virDomainGetGuestInfo()`` and ``virDomainAgentSetResponseTimeout()`` APIs + + The bhyve driver now implements ``virDomainGetGuestInfo()`` which returns + information about the guest, and ``virDomainAgentSetResponseTimeout()`` + which sets the guest agent response timeout. + + * bhyve: allow setting disk serial numbers + + The bhyve driver now allows specifying serial numbers for SATA disks and NVMe + controllers:: + + <disk type='file'> + <serial>BHYVE-SER01-0001</serial> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd1.img'/> + <target dev='hda' bus='sata' rotation_rate='7200'/> + </disk> + <controller type='nvme' index='0'> + <serial>BHYVE-NVME0-01234</serial> + </controller> + + It also supports specifying EUI-64 for the NVMe disks:: + + <disk type='file'> + <driver name='file' type='raw'/> + <source file='/path/to/some.img'/> + <target dev='nvme0n1' bus='nvme'/> + <wwn>01000000efbeadde</wwn> + </disk> + * **Improvements** * **Bug fixes** + * bhyve: fix domain API calls hanging after domain shutdown + v12.6.0 (2026-08-03) ==================== -- 2.55.0

2 1

[PATCH v2 0/7] qemu: add poll-weight support for iothreads
by Jaehoon Kim 24 Aug '26

24 Aug '26

This series adds support for the QEMU iothread poll-weight property, which controls the weight of the most recent event interval in the adaptive polling duration calculation. The valid range is [0, 63]; a value of 0 lets QEMU use its default weight. Changes in v2: - Move the formatdomain docs patch right after the XML parser/formatter patch - Fix the docs description: "If omitted, the value is not changed" rather than "If omitted or set to 0, the hypervisor selects a default" - Split the getter/stats path (patch 4) from the setter/cmdline path (patch 5), and drop the qemuBuildIOThreadCommandLine qemuCaps parameter since CAPS validation is handled by qemuValidateDomainDefIOThreads - Separate the test driver changes into its own patch (patch 6) with the corresponding iothreads.out updates split accordingly - Move the domstats documentation hunk into the stats patch (patch 4) - Add a qemuxmlconf parse-error test for out-of-range weight values - Fix Since version: 12.6.0 -> 12.7.0 (Peter Krempa) - Drop the docs: fix typos patch (already applied upstream) The series was validated with: meson test -C build virschematest meson test -C build qemucapabilitiestest meson test -C build qemuxmlconftest meson test -C build virshtest meson test -C build genericxml2xmltest QEMU commits: 9fea80ddf0 qapi/iothread: introduce poll-weight parameter for aio-poll 9563d0b5e2 aio-poll: refine iothread polling using weighted handler intervals ed21d9d65c aio-poll: avoid unnecessary polling time computation Jaehoon Kim (7): conf: add iothread poll-weight XML support docs: formatdomain: document iothread poll-weight qemu: capabilities: add capability for iothread poll-weight qemu: add poll-weight getter and stats support qemu: support iothread poll-weight test: add poll-weight support to the test driver virsh: add iothreadset --poll-weight support docs/formatdomain.rst | 8 ++- docs/manpages/virsh.rst | 18 ++++-- include/libvirt/libvirt-domain.h | 25 ++++++++ src/conf/domain_conf.c | 14 ++++- src/conf/domain_conf.h | 2 + src/conf/domain_validate.c | 7 +++ src/conf/schemas/domaincommon.rng | 5 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 6 ++ src/qemu/qemu_driver.c | 38 ++++++++++++ src/qemu/qemu_monitor.h | 2 + src/qemu/qemu_monitor_json.c | 18 ++++++ src/qemu/qemu_validate.c | 10 +++- src/test/test_driver.c | 12 ++++ tests/genericxml2xmlindata/iothreadids.xml | 2 +- .../caps_11.1.0_aarch64.xml | 1 + .../caps_11.1.0_x86_64.xml | 1 + ...s-poll-weight-outofrange.x86_64-latest.err | 1 + .../iothreads-ids-poll-weight-outofrange.xml | 58 +++++++++++++++++++ ...threads-ids-poll-weight.x86_64-latest.args | 40 +++++++++++++ ...othreads-ids-poll-weight.x86_64-latest.xml | 58 +++++++++++++++++++ .../iothreads-ids-poll-weight.xml | 58 +++++++++++++++++++ tests/qemuxmlconftest.c | 2 + tests/virshtestdata/iothreads.in | 2 + tests/virshtestdata/iothreads.out | 18 ++++++ tools/virsh-domain.c | 17 ++++++ 27 files changed, 415 insertions(+), 11 deletions(-) create mode 100644 tests/qemuxmlconfdata/iothreads-ids-poll-weight-outofrange.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/iothreads-ids-poll-weight-outofrange.xml create mode 100644 tests/qemuxmlconfdata/iothreads-ids-poll-weight.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iothreads-ids-poll-weight.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iothreads-ids-poll-weight.xml -- 2.54.0

3 17

[RFC PATCH v1 0/2] fix: don't add SELinux MCS categories to IOMMU device
by Omar Elghoul 24 Aug '26

24 Aug '26

Hi, This patchset proposes a fix for what I believe is a bug in libvirt when using iommufd under SELinux enforcing. It is an RFC because I cannot yet vouch for its correctness -- the goal is not to merge this code as is, but rather start a discussion on how we should go about things. When using iommufd, libvirt opens the vfio cdev corresponding to the device (e.g. /dev/vfio/devices/{n}) and the IOMMU device (/dev/iommu) and passes the file descriptors to qemu. The cdev is a device-specific resource, and thus a per-domain resource. The IOMMU on the other hand is a shared resource between all domains. Using the SELinux driver, libvirt relabels and assigns MCS categories to domain-specific devices to isolate from other domains. However, it also incorrectly assigns these categories to the IOMMU device. This can make subsequent domains unable to create DMA mappings. On my s390x host, I've repeatedly observed this problem showing up as PCI error events that show a DMA attempt to a non-present page. This problem is reproducible by running `setenforce 1` and then starting two domains, each with a PCI passthrough device using iommufd, and then performing actions that initiate PCI DMA transactions from within the guests. Launching qemu manually from the command-line does not produce these errors. There is also an additional cleanup problem that is not addressed in libvirt today, nor in my patches. When libvirt relabels a device, it doesn't restore the default label after the domain is destroyed. This is fine for the vfio cdevs, because they will disappear anyway as they get unbound from the vfio driver and rebind their default driver, but again is problematic for /dev/iommu because the inode is never unlinked. For example, the good state before starting a domain: root in ~/libvirt λ matchpathcon /dev/iommu /dev/iommu system_u:object_r:iommu_device_t:s0 root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:iommu_device_t:s0 /dev/iommu After starting and ending all domains (without my patches): root in ~/libvirt λ ls -Z /dev/iommu system_u:object_r:svirt_image_t:s0:c614,c980 /dev/iommu My patches remove the per-domain MCS categories (i.e., c614,c980) from the IOMMU, but they do NOT clean up the inode relabel. For the domain's lifetime, a relabel from iommu_device_t to svirt_image_t is correct. But I'm skeptical of whether we should clean that up at all when no domains are running, so that's another point I hope to get sorted out. I'd be happy to hear any feedback or thoughts on resolving this issue. If there's more questions or anyone needs more details, I'm available to answer those too. Thanks in advance. Omar Elghoul (2): security: add SetSharedImageFDLabel() for shared image FDs qemu: drop per-domain MCS categories from IOMMU device src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 1 + src/security/security_driver.h | 4 ++ src/security/security_manager.c | 16 ++++++++ src/security/security_manager.h | 3 ++ src/security/security_nop.c | 1 + src/security/security_selinux.c | 63 ++++++++++++++++++++++++++++++++ src/security/security_stack.c | 18 +++++++++ 11 files changed, 111 insertions(+), 2 deletions(-) -- 2.55.0

3 9

[PATCH 0/4] bhyve: live/transient domain handling fixes
by Roman Bogorodskiy 24 Aug '26

24 Aug '26

I was doing pre-merge testing of the "bhyve: implement virDomainSetLifecycleAction() API" series and spotted a few issues related to the live/transient domain definitions handling (and in the original series as well, so will likely send a v2 later). This area has quite a few nuances, so I extended the TCK test: https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/92 TCK also helped to catch the issue with the firmware data filling with the scripts/domain/405-ovmf-nvram-efi.t test. It is fixed in the final patch of the series. I think I plan to add more TCK tests for that, but decided to send this series first to make sure I'm on the right track. Roman Bogorodskiy (4): bhyve: process: do not leak live changes to persistent XML bhyve: process: discard stale live definition on reconnect failure bhyve: honor VIR_DOMAIN_XML_INACTIVE in virDomainGetXMLDesc() bhyve: domain: fix filling of firmware data src/bhyve/bhyve_domain.c | 11 ++++++++++- src/bhyve/bhyve_driver.c | 18 ++++++++++++++---- src/bhyve/bhyve_firmware.c | 12 ++++++------ src/bhyve/bhyve_firmware.h | 2 +- src/bhyve/bhyve_process.c | 9 ++++++++- .../three_firmwares/BHYVE_UEFI_VARS.fd | 0 .../x86_64/bhyvexml2xmlout-numa.xml | 2 ++ tests/bhyvexml2xmltest.c | 10 +++++++++- 8 files changed, 50 insertions(+), 14 deletions(-) create mode 100644 tests/bhyvefirmwaredata/three_firmwares/BHYVE_UEFI_VARS.fd -- 2.52.0

2 5

[PATCH] bhyve: allow setting eui64 for NVMe disks
by Roman Bogorodskiy 24 Aug '26

24 Aug '26

Bhyve allows to set eui64 for the NVMe disks: eui64 IEEE Extended Unique Identifier (8 byte value). And in a real command line: -s 5:0,nvme,/data/img/10gb.img,ser=BHYVE-NVME01-F000,eui64=0x01000000efbeadde Model that using the <wwn> element: <disk type='file'> <driver name='file' type='raw'/> <source file='/path/to/some.img'/> <target dev='nvme0n1' bus='nvme'/> <wwn>01000000efbeadde</wwn> </disk> As this element does not allow commas, it's not necessary to add additional validation for that. Closes: https://gitlab.com/libvirt/libvirt/-/work_items/901 Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- I think there's a bug in bhyve that results in a reversed order value, so I have to use "01000000efbeadde" to get "deadbeef00000001". I'm trying to address that in https://reviews.freebsd.org/D59080. src/bhyve/bhyve_command.c | 4 ++++ .../x86_64/bhyvexml2argv-2-nvme-2-controllers.args | 2 +- .../x86_64/bhyvexml2argv-2-nvme-2-controllers.xml | 1 + .../x86_64/bhyvexml2argv-nvme-explicit-controller.args | 2 +- .../x86_64/bhyvexml2argv-nvme-explicit-controller.xml | 1 + .../x86_64/bhyvexml2xmlout-2-nvme-2-controllers.xml | 1 + .../x86_64/bhyvexml2xmlout-nvme-explicit-controller.xml | 1 + 7 files changed, 10 insertions(+), 2 deletions(-) diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index 956fcab06c..f0a87cffea 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -479,6 +479,10 @@ bhyveBuildNVMeControllerArgStr(const virDomainDef *def, virBufferAsprintf(&opt, ",maxq=%d", disk->queues); if (disk->queue_size) virBufferAsprintf(&opt, ",qsz=%d", disk->queue_size); + if (disk->wwn) + virBufferAsprintf(&opt, ",eui64=%s%s", + STRPREFIX(disk->wwn, "0x") ? "" : "0x", + disk->wwn); if (controller->opts.nvmeopts.serial) virBufferAsprintf(&opt, ",ser=%s", controller->opts.nvmeopts.serial); diff --git a/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-nvme-2-controllers.args b/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-nvme-2-controllers.args index 664eec99bc..5be39bda1d 100644 --- a/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-nvme-2-controllers.args +++ b/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-nvme-2-controllers.args @@ -5,6 +5,6 @@ bhyve \ -H \ -P \ -s 0:0,hostbridge \ --s 2:0,nvme,/tmp/freebsd.img \ +-s 2:0,nvme,/tmp/freebsd.img,eui64=0xdeadbeef00000001 \ -s 3:0,nvme,/tmp/data.img \ bhyve diff --git a/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-nvme-2-controllers.xml b/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-nvme-2-controllers.xml index 30f337197e..6a5efd3831 100644 --- a/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-nvme-2-controllers.xml +++ b/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-2-nvme-2-controllers.xml @@ -11,6 +11,7 @@ <driver name='file' type='raw'/> <source file='/tmp/freebsd.img'/> <target dev='nvme0n1' bus='nvme'/> + <wwn>0xdeadbeef00000001</wwn> </disk> <disk type='file'> <driver name='file' type='raw'/> diff --git a/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.args b/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.args index 74dd4baa37..022a4df209 100644 --- a/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.args +++ b/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.args @@ -5,5 +5,5 @@ bhyve \ -H \ -P \ -s 0:0,hostbridge \ --s 2:0,nvme,/tmp/freebsd.img,maxq=2,qsz=256,ser=BHYVE-NVME0-01234 \ +-s 2:0,nvme,/tmp/freebsd.img,maxq=2,qsz=256,eui64=0x01000000efbeadde,ser=BHYVE-NVME0-01234 \ bhyve diff --git a/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.xml b/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.xml index 9781d3aaef..fb7ed573c5 100644 --- a/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.xml +++ b/tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.xml @@ -14,6 +14,7 @@ <driver name='file' type='raw' queues='2' queue_size='256'/> <source file='/tmp/freebsd.img'/> <target dev='nvme0n1' bus='nvme'/> + <wwn>01000000efbeadde</wwn> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> </devices> diff --git a/tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-2-nvme-2-controllers.xml b/tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-2-nvme-2-controllers.xml index d0eb9c7fc8..107beef587 100644 --- a/tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-2-nvme-2-controllers.xml +++ b/tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-2-nvme-2-controllers.xml @@ -17,6 +17,7 @@ <driver name='file' type='raw'/> <source file='/tmp/freebsd.img'/> <target dev='nvme0n1' bus='nvme'/> + <wwn>0xdeadbeef00000001</wwn> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='disk'> diff --git a/tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-nvme-explicit-controller.xml b/tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-nvme-explicit-controller.xml index f646267ec5..7c4dd2cdb3 100644 --- a/tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-nvme-explicit-controller.xml +++ b/tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-nvme-explicit-controller.xml @@ -17,6 +17,7 @@ <driver name='file' type='raw' queues='2' queue_size='256'/> <source file='/tmp/freebsd.img'/> <target dev='nvme0n1' bus='nvme'/> + <wwn>01000000efbeadde</wwn> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='nvme' index='0'> -- 2.52.0

2 1