| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| backport/apparmor-Allow-umount-dev.patch | apparmor: Allow umount(/dev) Commit 379c0ce4bfed introduced a call to umount(/dev) performed inside the namespace that we run QEMU in. As a result of this, on machines using AppArmor, VM startup now fails with internal error: Process exited prior to exec: libvirt: QEMU Driver error: failed to umount devfs on /dev: Permission denied The corresponding denial is AVC apparmor="DENIED" operation="umount" profile="libvirtd" name="/dev/" pid=70036 comm="rpc-libvirtd" Extend the AppArmor configuration for virtqemud and libvirtd so that this operation is allowed. (cherry picked from commit ef4829510549ec68cf80774e98b200a3e7bbe51f) |
Andrea Bolognani <abologna@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/ef4829510549ec68cf80774e98b200a3e7bbe51f | 2023-01-18 | |
| backport/qemu_interface-Fix-managed-no-case-when-creating-an-ether.patch | qemu_interface: Fix managed='no' case when creating an ethernet interface In a recent commit of v9.0.0-rc1~192 I've tried to forbid case where a TAP device already exists, but at the same time it's managed by Libvirt (<interface type='ethernet'> <target dev='tap0' managed='yes'/> </interface>). NB, if @managed attribute is missing then it's assumed to be managed by Libvirt. Anyway, I've mistakenly put setting of VIR_NETDEV_TAP_CREATE_ALLOW_EXISTING flag into managed='yes' branch instead of managed='no' branch in qemuInterfaceEthernetConnect(). Move the setting of the flag into the correct branch. (cherry picked from commit d6a8b9eef70887e01fa5fd292580e14ca5eab08c) |
Michal Privoznik <mprivozn@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/d6a8b9eef70887e01fa5fd292580e14ca5eab08c | 2023-01-23 | |
| backport/qemu_domain-Don-t-unref-NULL-hash-table-in-qemuDomainRefr.patch | qemu_domain: Don't unref NULL hash table in qemuDomainRefreshStatsSchema() The g_hash_table_unref() function does not accept NULL. Passing NULL results in a glib warning being triggered. Check whether the hash table is not NULL and unref it only then. (cherry picked from commit c3afde9211b550d3900edc5386ab121f5b39fd3e) |
Michal Privoznik <mprivozn@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commit/c3afde9211b550d3900edc5386ab121f5b39fd3e | 2023-01-26 |
| backport/qemu-Jump-to-cleanup-label-on-umount-failure.patch | qemu: Jump to cleanup label on umount failure Similar to other error paths in qemuDomainUnshareNamespace(), jump to the cleanup label on umount error instead of directly returning -1. (cherry picked from commit c3f16cea3bef578c498c720aa90c677ee9511e2f) |
Jim Fehlig <jfehlig@suse.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/c3f16cea3bef578c498c720aa90c677ee9511e2f | 2023-02-06 | |
| backport/qemu_namespace-Deal-with-nested-mounts-when-umount-ing-de.patch | qemu_namespace: Deal with nested mounts when umount()-ing /dev In one of recent commits (v9.0.0-rc1~106) I've made our QEMU namespace code umount the original /dev. One of the reasons was enhanced security, because previously we just mounted a tmpfs over the original /dev. Thus a malicious QEMU could just umount("/dev") and it would get to the original /dev with all nodes. Now, on some systems this introduced a regression: failed to umount devfs on /dev: Device or resource busy But how this could be? We've moved all file systems mounted under /dev to a temporary location. Or have we? As it turns out, not quite. If there are two file systems mounted on the same target, e.g. like this: mount -t tmpfs tmpfs /dev/shm/ && mount -t tmpfs tmpfs /dev/shm/ then only the top most (i.e. the last one) is moved. See qemuDomainUnshareNamespace() for more info. Now, we could enhance our code to deal with these "doubled" mount points. Or, since it is the top most file system that is accessible anyways (and this one is preserved), we can umount("/dev") in a recursive fashion. (cherry picked from commit 5155ab4b2a704285505dfea6ffee8b980fdaa29e) |
Michal Privoznik <mprivozn@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/5155ab4b2a704285505dfea6ffee8b980fdaa29e | 2023-02-07 | |
| backport/qemuProcessRefreshDisks-Don-t-skip-filling-of-disk-inform.patch | qemuProcessRefreshDisks: Don't skip filling of disk information if tray state didn't change Commit 5ef2582646eb98 added emitting of even when refreshign disk state, where it wanted to avoid sending the event if disk state didn't change. This was achieved by using 'continue' in the loop filling the information. Unfortunately this skips extraction of whether the device has a tray which is propagated into internal structures, which in turn broke cdrom media change as the code thought there's no tray for the device. (cherry picked from commit 86cfe93ef7fdc2d665a2fc88b79af89e7978ba78) |
Peter Krempa <pkrempa@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/86cfe93ef7fdc2d665a2fc88b79af89e7978ba78 | 2023-02-09 | |
| backport/qemu_extdevice-Do-cleanup-host-only-for-VIR_DOMAIN_TPM_TY.patch | qemu_extdevice: Do cleanup host only for VIR_DOMAIN_TPM_TYPE_EMULATOR We only set up host for VIR_DOMAIN_TPM_TYPE_EMULATOR and thus similarly, we should do cleanup for the same type. This also fixes a crasher, in which qemuTPMEmulatorCleanupHost() accesses tpm->data.emulator.storagepath which is NULL for VIR_DOMAIN_TPM_TYPE_EXTERNAL. (cherry picked from commit 03f76e577d66f8eea6aa7cc513e75026527b4cda) |
Michal Privoznik <mprivozn@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/03f76e577d66f8eea6aa7cc513e75026527b4cda | 2023-02-10 | |
| backport/qemu-blockjob-Handle-pending-blockjob-state-only-when-we-.patch | qemu: blockjob: Handle 'pending' blockjob state only when we need it The 'pending' state needs to be handled by the blockjob code only when the snapshot code requests a block-commit without auto-finalization. If we always handle it we fail to properly remove the blockjob data for the 'blockdev-create' job as that also transitions trhough 'pending' but we'd never update it once it reaches 'concluded' as the code already thinks that the job has finished and is no longer watching it. Introduce a 'processPending' property into block job data and set it only when we know that we need to process 'pending'. (cherry picked from commit c433c2434c0459df98ed3355ef615e341acd9009) |
Peter Krempa <pkrempa@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/c433c2434c0459df98ed3355ef615e341acd9009 | 2023-02-10 | |
| backport/rpc-client-Don-t-check-return-value-of-virNetMessageNew.patch | rpc: client: Don't check return value of virNetMessageNew virNetServerClientDispatchRead checked the return value but it's not necessary any more as it can't return NULL nowadays. (cherry picked from commit 761cb8a0876d32445951791030c77afa147c0de1) |
Peter Krempa <pkrempa@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/761cb8a0876d32445951791030c77afa147c0de1 | 2023-02-15 | |
| backport/rpc-Don-t-warn-about-max_client_requests-in-single-thread.patch | rpc: Don't warn about "max_client_requests" in single-threaded daemons The warning about max_client_requests is hit inside virtlogd every time a VM starts which spams the logs. Emit the warning only when the client request limit is not 1 and add a warning into the daemon config to not configure it too low instead. (cherry picked from commit b3f8e072fe08a6beaf3ec3d27e02efee4358b2ca) |
Peter Krempa <pkrempa@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/b3f8e072fe08a6beaf3ec3d27e02efee4358b2ca | 2023-02-15 | |
| backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch | conf: Fix migration in some firmware autoselection scenarios Introduce a small kludge in the parser to avoid unnecessarily blocking incoming migration from a range of recent libvirt releases. https://bugzilla.redhat.com/show_bug.cgi?id=2184966 (cherry picked from commit f9ad3023355bcbfc692bbe4997fdfa774866a980) Conflicts: * tests/qemuxml2argvtest.c * tests/qemuxml2xmltest.c - missing unrelated changes in the surrounding tests * tests/qemuxml2argvdata/firmware-manual-efi-features.x86_64-latest.args * tests/qemuxml2xmloutdata/firmware-manual-efi-features.x86_64-latest.xml - had to be regenerated due to missing changes in the test program |
Andrea Bolognani <abologna@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/f9ad3023355bcbfc692bbe4997fdfa774866a980 | 2023-04-11 | |
| backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch | virpci: Resolve leak in virPCIVirtualFunctionList cleanup Repeatedly querying an SR-IOV PCI device's capabilities exposes a memory leak caused by a failure to free the virPCIVirtualFunction array within the parent struct's g_autoptr cleanup. Valgrind output after getting a single interface's XML description 1000 times: ==325982== 256,000 bytes in 1,000 blocks are definitely lost in loss record 2,634 of 2,635 ==325982== at 0x4C3C096: realloc (vg_replace_malloc.c:1437) ==325982== by 0x59D952D: g_realloc (in /usr/lib64/libglib-2.0.so.0.5600.4) ==325982== by 0x4EE1F52: virReallocN (viralloc.c:52) ==325982== by 0x4EE1FB7: virExpandN (viralloc.c:78) ==325982== by 0x4EE219A: virInsertElementInternal (viralloc.c:183) ==325982== by 0x4EE23B2: virAppendElement (viralloc.c:288) ==325982== by 0x4F65D85: virPCIGetVirtualFunctionsFull (virpci.c:2389) ==325982== by 0x4F65753: virPCIGetVirtualFunctions (virpci.c:2256) ==325982== by 0x505CB75: virNodeDeviceGetPCISRIOVCaps (node_device_conf.c:2969) ==325982== by 0x505D181: virNodeDeviceGetPCIDynamicCaps (node_device_conf.c:3099) ==325982== by 0x505BC4E: virNodeDeviceUpdateCaps (node_device_conf.c:2677) ==325982== by 0x260FCBB2: nodeDeviceGetXMLDesc (node_device_driver.c:355) (cherry picked from commit 6425a311b8ad19d6f9c0b315bf1d722551ea3585) https://bugs.debian.org/1036297 https://security-tracker.debian.org/tracker/CVE-2023-2700 |
Tim Shearer <TShearer@adva.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/6425a311b8ad19d6f9c0b315bf1d722551ea3585 | 2023-05-01 | |
| backport/virsh-Make-domif-setlink-work-more-than-once.patch | virsh: Make domif-setlink work more than once In virsh, we have this convenient domif-setlink command, which is just a wrapper over virDomainUpdateDeviceFlags() and which allows setting link state of given guest NIC. It does so by fetching corresponding <interface/> XML snippet and either putting <link state=''/> into it, OR if the element already exists setting the attribute to desired value. The XML is then fed into the update API. There's, however, a small bug in detecting the pre-existence of the element and its attribute. The code looks at "link" attribute, while in fact, the attribute is called "state". (cherry-picked from commit 6f3f6c0f763b9ffd8ef93eb124c88dd0b79138fc) |
Michal Privoznik <mprivozn@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commit/6f3f6c0f763b9ffd8ef93eb124c88dd0b79138fc | 2023-01-30 |
| backport/storage-Fix-returning-of-locked-objects-from-virStoragePo.patch | storage: Fix returning of locked objects from 'virStoragePoolObjListSearch' CVE-2023-3750 'virStoragePoolObjListSearch' explicitly documents that it's returning a pointer to a locked and ref'd pool that maches the lookup function. This was not the case as in commit 0c4b391e2a9 (released in libvirt-8.3.0) the code was accidentally converted to use 'VIR_LOCK_GUARD' which auto-unlocked it when leaving the scope, even when the code was originally "leaking" the lock. Revert the corresponding conversion and add a comment that this function is intentionally leaking a locked object. (cherry picked from commit 9a47442366fcf8a7b6d7422016d7bbb6764a1098) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commit/9a47442366fcf8a7b6d7422016d7bbb6764a1098 | 2023-07-13 |
| backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch | Fix off-by-one error in udevListInterfacesByStatus Ever since this function was introduced in 2012 it could've tried filling in an extra interface name. That was made worse in 2019 when the caller functions started accepting NULL arrays of size 0. This is assigned CVE-2024-1441. (cherry picked from commit c664015fe3a7bf59db26686e9ed69af011c6ebb8) Conflicts: * NEWS.rst - missing context; the hunk is not relevant to the Debian package anyway and has been dropped |
Martin Kletzander <mkletzan@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commit/c664015fe3a7bf59db26686e9ed69af011c6ebb8 | 2024-02-27 |
| backport/remote-check-for-negative-array-lengths-before-allocation.patch | remote: check for negative array lengths before allocation While the C API entry points will validate non-negative lengths for various parameters, the RPC server de-serialization code will need to allocate memory for arrays before entering the C API. These allocations will thus happen before the non-negative length check is performed. Passing a negative length to the g_new0 function will usually result in a crash due to the negative length being treated as a huge positive number. This was found and diagnosed by ALT Linux Team with AFLplusplus. CVE-2024-2494 (cherry picked from commit 8a3f8d957507c1f8223fdcf25a3ff885b15557f2) |
=?utf-8?b?IkRhbmllbCBQLiBCZXJyYW5nw6ki?= <berrange@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commit/8a3f8d957507c1f8223fdcf25a3ff885b15557f2 | 2024-03-15 |
| backport/interface-fix-udev_device_get_sysattr_value-return-value-.patch | interface: fix udev_device_get_sysattr_value return value check Reviewing the code I found that return value of function udev_device_get_sysattr_value() is dereferenced without a check. udev_device_get_sysattr_value() may return NULL by number of reasons. v2: VIR_DEBUG added, replaced STREQ(NULLSTR()) with STREQ_NULLABLE() v3: More checks added, to skip earlier. More verbose VIR_DEBUG. (cherry picked from commit 2ca94317ac642a70921947150ced8acc674ccdc8) Conflicts: * src/interface/interface_backend_udev.c - slightly different (but functionally identical) format string due to not having commit be664663fab7c3fe008595767404ee2868f41a31 CVE-2024-2496 |
Dmitry Frolov <frolov@swemel.ru> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/2ca94317ac642a70921947150ced8acc674ccdc8 | 2023-09-12 | |
| backport/qemu-domain-Fix-logic-when-tainting-domain.patch | qemu: domain: Fix logic when tainting domain Originally the code was skipping all repeated taints with the same taint flag but a logic bug introduced in commit 30626ed15b239c424ae inverted the condition. This caused that actually the first occurence was NOT logged but any subsequent was. This was noticed when going through oVirt logs as they use custom guest agent commands and the logs are totally spammed with this message. (cherry picked from commit 9134b40d0b43a5e1a9928b0a0d948205941d9807) |
Peter Krempa <pkrempa@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/9134b40d0b43a5e1a9928b0a0d948205941d9807 | 2023-03-01 | |
| backport/qemu_process-Skip-over-non-virtio-non-TAP-NIC-models-when.patch | qemu_process: Skip over non-virtio non-TAP NIC models when refreshing rx-filter After guest is started, or we are reconnecting to already running one (after daemon restart), qemuProcessRefreshRxFilters() is called to refresh rx-filters (basically MAC addresses of guest NICs) as they might have changed while we were not running (for the case when reconnecting to an already running guest), or we need to enable them by running a command (for freshly started guest - see processNicRxFilterChangedEvent()). Now, our XML parser allowed trustGuestRxFilters attribute for all types and models of <interface/> while in reality, only virtio model AND TUN/TAP based types can see MAC address changes. For other combinations, QEMU reports an error. This all means that when the daemon is restarted and it reconnects to a guest with, well invalid configuration, or when such guest is restored from a saved image, or migrated then we issue the monitor command, to which QEMU replies with an error which is then propagated to users: error: internal error: unable to execute QEMU command 'query-rx-filter': invalid net client name: hostdev0 While on one hand users should fix their configuration (and after v10.0.0-rc1~123 they can do that even on live domains), libvirt can also has some logic built in that prevent issuing the command in the first place (for obviously wrong cases). (cherry picked from commit bee5301afa55a28090c0262f34c84762120bf878) |
Michal Privoznik <mprivozn@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/bee5301afa55a28090c0262f34c84762120bf878 | 2024-01-23 | |
| backport/apparmor-Allow-running-i686-VMs-on-Debian-12.patch | apparmor: Allow running i686 VMs on Debian 12 In Debian 12, the qemu-system-i386 binary in /usr/bin is a wrapper script, with the actual executable living in /usr/libexec instead. This makes it impossible to run i686 VMs when AppArmor is enabled. Allow running the actual binary. https://bugs.debian.org/1030926 (cherry picked from commit 81493d8eb6ec5d3f063b0b5770df33ed656d6766) |
Andrea Bolognani <abologna@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/81493d8eb6ec5d3f063b0b5770df33ed656d6766 | 2024-10-15 | |
| forward/Skip-vircgrouptest.patch | Skip vircgrouptest We don't have a mock for nodeGetCPUCount yet so we fail in a chroot without sysfs mounted. |
=?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2014-03-07 | ||
| forward/Reduce-udevadm-settle-timeout-to-10-seconds.patch | Reduce udevadm settle timeout to 10 seconds This isn't a proper fix but it will make virt-manager at least start. |
=?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2012-06-04 | ||
| forward/Pass-GPG_TTY-env-var-to-the-ssh-binary.patch | Pass GPG_TTY env var to the ssh binary gpg-agent(1) can emulate the OpenSSH Agent protocol (which provides pubkey-authentication using an authentication-capable OpenPGP key, in addition to the usual identity files). However for a console-based password prompt to work, the 'GPG_TTY' environment variable needs to be set to the current TTY. Furthermore, curses-based password prompts also require the 'TERM' environment variable to be set to the terminal type. |
Guilhem Moulin <guilhem@guilhem.org> | no | 2016-12-09 | ||
| debian/Debianize-libvirt-guests.patch | Debianize libvirt-guests | =?utf-8?q?Laurent_L=C3=A9onard?= <laurent@open-minds.org> | not-needed | 2010-12-09 | ||
| debian/Debianize-systemd-service-files.patch | Debianize systemd service files | =?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | not-needed | 2012-06-26 | ||
| debian/apparmor_profiles_local_include.patch | apparmor_profiles_local_include Include local apparmor profile |
Felix Geyer <fgeyer@debian.org> | not-needed | 2015-08-11 | ||
| debian/Use-sensible-editor-by-default.patch | Use sensible-editor by default It is the reasonable default for Debian. |
Andrea Bolognani <eof@kiyuko.org> | not-needed | 2020-08-18 | ||
| debian/Disable-passt-support.patch | Disable passt support Rejecting the value from the XML parser ensures that all the code related to passt, which is left untouched, is never executed. The error message reported in this case is the same that virXMLPropEnum() would generate when encountering a value that doesn't exist in the enum. |
Andrea Bolognani <eof@kiyuko.org> | not-needed | 2023-02-25 |