| 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 | |
| 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 |