| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| CVE-2021-3631.patch | security: fix SELinux label generation logic A process can access a file if the set of MCS categories for the file is equal-to *or* a subset-of, the set of MCS categories for the process. If there are two VMs: a) svirt_t:s0:c117 b) svirt_t:s0:c117,c720 Then VM (b) is able to access files labelled for VM (a). IOW, we must discard case where the categories are equal because that is a subset of many other valid category pairs. |
Daniel P. Berrangé <berrange@redhat.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/15073504dbb624d3f6c911e85557019d3620fdb2 | 2021-06-28 |
| CVE-2021-3667.patch | storage_driver: Unlock object on ACL fail in storagePoolLookupByTargetPath 'virStoragePoolObjListSearch' returns a locked and refed object, thus we must release it on ACL permission failure. |
Peter Krempa <pkrempa@redhat.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/447f69dec47e1b0bd15ecd7cd49a9fd3b050fb87 | 2021-07-21 |
| backport/apparmor-let-image-label-setting-loop-over-backing-files.patch | apparmor: let image label setting loop over backing files When adding a rule for an image file and that image file has a chain of backing files then we need to add a rule for each of those files. To get that iterate over the backing file chain the same way as dac/selinux already do and add a label for each. (cherry picked from commit d51ad0008dc2df0257f69e767ab3e3c5fd1457ff) |
Christian Ehrhardt <christian.ehrhardt@canonical.com> | no | 2021-01-13 | ||
| backport/meson-Fix-cross-building-of-dtrace-probes.patch | meson: Fix cross-building of dtrace probes dtrace invokes the C compiler, so when cross-building we need to make sure that $CC is set in the environment and that it points to the cross-compiler rather than the native one. Until https://github.com/mesonbuild/meson/issues/266 is addressed, the workaround is to call dtrace via env(1). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980334 (cherry picked from commit 44b348134cd6724e35984a553f8d54d27aa22711) |
Helmut Grohne <helmut@subdivi.de> | no | 2021-01-19 | ||
| backport/Fix-reboot-command-for-LXC-containers.patch | Fix reboot command for LXC containers (Closes: #991773) The virNetDaemonQuit(dmn) command in virLXCControllerSignalChildIO triggers an early close of all clients of lxc_controller. Here, libvirtd itself is a client of this controller, and the client connection is used to notify libvirtd if a reboot of the container is required. However, the client connection was closed before such a status could be sent to libvirtd. To fix this bug, we will immediately send the reboot or shutdown status of the container to libvirtd, and only after client disconnect will we trigger virNetDaemonQuit (Closes: #991773). (cherry picked from commit 93c47e2c39521aba760486f0238458ef1a37490c) In order to cleanly apply to libvirt 7.0.0, this patch needed some minor adjustments, e.g., "virNetDaemon *dmn" vs "virNetDaemonPtr dmn" in libvirt 7.0.0. |
Joachim Falk <joachim.falk@gmx.de> | no | debian | 2021-12-02 | |
| revert/systemd-Revert-remote-Add-libvirtd-dependency-to-virt-gue.patch | systemd: Revert "remote: Add libvirtd dependency to virt-guest-shutdown.target" as it would reintroduce bug 955216 This reverts commit f035f53baa2e5dc00b8e866e594672a90b4cea78. |
Christian Ehrhardt <christian.ehrhardt@canonical.com> | no | 2021-01-27 | ||
| 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> | no | vendor | 2010-12-09 | |
| debian/Debianize-libvirtd.patch | Debianize libvirtd | Andrea Bolognani <eof@kiyuko.org> | no | 2021-02-14 | ||
| debian/Debianize-systemd-service-files.patch | Debianize systemd service files | =?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2012-06-26 | ||
| debian/apparmor_profiles_local_include.patch | apparmor_profiles_local_include Include local apparmor profile |
Felix Geyer <fgeyer@debian.org> | no | 2015-08-11 | ||
| debian/Set-defaults-for-zfs-tools.patch | Set defaults for zfs tools so we don't have to build-depend on a program in contrib |
=?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2016-08-14 | ||
| debian/Revert-m4-virt-xdr-rewrite-XDR-check.patch | Revert "m4: virt-xdr: rewrite XDR check" This reverts commit d7147b3797380de2d159ce6324536f3e1f2d97e3. Reasoning: The build against libtirpc causes linking errors using the headers of libtirpc but calling into the compat functions of glibc as discussed here: https://www.redhat.com/archives/libvir-list/2020-August/msg00921.html Current glibc 2.31-0ubuntu1 and 2.31-3 for us are built with --enable-obsolete-rpc which then leads to the wrong linking. What happens otherwise is a crash like: [582093.524644] libvirt_lxc[261446]: segfault at 0 ip 0000000000000000 sp 00007ffdd2345598 error 14 in libvirt_lxc[5587e42aa000+8000] [582093.524650] Code: Bad RIP value. The reason is that due to bad linking (should link to 3.0 versions instead): $ eu-readelf -a /usr/lib/libvirt/libvirt_lxc | grep xdr_uint64 0x0000000000026820 X86_64_JUMP_SLOT 000000000000000000 +0 xdr_uint64_t 99: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF xdr_uint64_t GLIBC_2 2 5 (4) [ 1c02] xdr_uint64_t It will use the headers and structs of libtirpc but then call ito glibc which breaks badly. As soon as we rebuild agains 2.32 which is about to arrive we can drop this revert and follow upstream as 2.32 dropped the option to enable --enable-obsolete-rpc. |
Christian Ehrhardt <christian.ehrhardt@canonical.com> | no | 2020-08-26 | ||
| debian/Use-sensible-editor-by-default.patch | Use sensible-editor by default It is the reasonable default for Debian. |
Andrea Bolognani <eof@kiyuko.org> | no | 2020-08-18 | ||
| backport/vircgroup-Fix-virCgroupKillRecursive-wrt-nested-controlle.patch | vircgroup: Fix virCgroupKillRecursive() wrt nested controllers I've encountered the following bug, but only on Gentoo with systemd and CGroupsV2. I've started an LXC container successfully but destroying it reported the following error: error: Failed to destroy domain 'amd64' error: internal error: failed to get cgroup backend for 'pathOfController' Debugging showed, that CGroup hierarchy is full of surprises: /sys/fs/cgroup/machine.slice/machine-lxc\x2d861\x2damd64.scope/ └── libvirt ├── dev-hugepages.mount ├── dev-mqueue.mount ├── init.scope ├── sys-fs-fuse-connections.mount ├── sys-kernel-config.mount ├── sys-kernel-debug.mount ├── sys-kernel-tracing.mount ├── system.slice │ ├── console-getty.service │ ├── dbus.service │ ├── system-getty.slice │ ├── system-modprobe.slice │ ├── systemd-journald.service │ ├── systemd-logind.service │ └── tmp.mount └── user.slice For comparison, here's the same container on recent Rawhide: /sys/fs/cgroup/machine.slice/machine-lxc\x2d13550\x2damd64.scope/ └── libvirt Anyway, those nested directories should not be a problem, because virCgroupKillRecursiveInternal() removes them recursively, right? Sort of. The function really does remove nested directories, but it assumes that every directory has the same controller as the rest. Just take a look at virCgroupV2KillRecursive() - it gets 'Any' controller (the first one it found in ".scope") and then passes it to virCgroupKillRecursiveInternal(). This assumption is not true though. The controllers found in ".scope" are the following: cpuset cpu io memory pids while "libvirt" has fewer: cpuset cpu io memory Up until now it's not problem, because of how we order controllers internally - "cpu" is the first and thus picking "Any" controller returns just that. But the rest of directories has no controllers, their "cgroup.controllers" is just empty. What fixes the bug is dropping @controller argument from virCgroupKillRecursiveInternal() and letting each iteration work pick its own controller. (cherry picked from commit ea7d0ca37cce76e1327945c4864b996d7fd6d2e6) |
Michal Privoznik <mprivozn@redhat.com> | no | 2021-04-16 | ||
| backport/tests-Fix-libxlxml2domconfigtest-with-latest-xen.patch | tests: Fix libxlxml2domconfigtest with latest xen shadow_memkb is populated from a libxl API call, and the value can change. For example: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2c992810854a15b41be920519ce83a4a328d5168 Mock libxl_get_required_shadow_memory to give consistent output (cherry picked from commit 72d4709ab901dd3699d342f15ca3aff9bffddf96) |
Cole Robinson <crobinso@redhat.com> | no | 2022-10-27 | ||
| backport/tests-Fix-libxlxml2domconfigtest.patch | tests: Fix libxlxml2domconfigtest Downstream CI recently encountered failures of libxlxml2domconfigtest when building libvirt packages against Xen 4.17 rc3 packages. The test fails on vnuma_hvm config, where suddently the actual json produced by libxl_domain_config_to_json() contains a 'pnode' entry in the 'vnuma_nodes' list, which is absent in the expected json. It appears the test has thus far passed by luck. E.g. I was able to make the test pass in the failing environment by changing the meson buildtype from debugoptimized to debug. When a VM config contains vnuma settings, libxlMakeVnumaList() checks if the number of requested vnuma nodes exceeds the number of physical nodes. The number of physical nodes is retrieved with libxl_get_physinfo(), which can return wildly different results in the context of unit tests. This change mocks libxl_get_physinfo() to return consistent results. All fields of the libxl_physinfo struct are set to 0 except nr_nodes, which is set to 6 to ensure the vnuma_hvm configuration is properly tested. (cherry picked from commit f81ee7b549242c93bead8c8772bb31047da00415) |
Jim Fehlig <jfehlig@suse.com> | no | 2022-11-10 | ||
| CVE-2021-3975.patch | qemu: Add missing lock in qemuProcessHandleMonitorEOF qemuMonitorUnregister will be called in multiple threads (e.g. threads in rpc worker pool and the vm event thread). In some cases, it isn't protected by the monitor lock, which may lead to call g_source_unref more than one time and a use-after-free problem eventually. Add the missing lock in qemuProcessHandleMonitorEOF (which is the only position missing lock of monitor I found). |
Peng Liang <liangpeng10@huawei.com> | yes | debian upstream | https://github.com/libvirt/libvirt/commit/1ac703a7d0789e46833f4013a3876c2e3af18ec7 | 2021-02-24 |
| libxl-Fix-domain-shutdown.patch | libxl: Fix domain shutdown Commit fa30ee04a2 caused a regression in normal domain shutown. Initiating a shutdown from within the domain or via 'virsh shutdown' does cause the guest OS running in the domain to shutdown, but libvirt never reaps the domain so it is always shown in a running state until calling 'virsh destroy'. The shutdown thread is also an internal user of the driver shutdown machinery and eventually calls libxlDomainDestroyInternal where the ignoreDeathEvent inhibitor is set, but running in a thread introduces the possibility of racing with the death event from libxl. This can be prevented by setting ignoreDeathEvent before running the shutdown thread. An additional improvement is to handle the destroy event synchronously instead of spawning a thread. The time consuming aspects of destroying a domain have been completed when the destroy event is delivered. |
Jim Fehlig <jfehlig@suse.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/87a9d3a6b01baebdca33d95ad0e79781b6a46ca8 | 2021-02-19 |
| CVE-2021-4147_1.patch | libxl: Disable death events after receiving a shutdown event The libxl driver will handle all domain destruction and cleanup when receiving a domain shutdown event from libxl. Commit fa30ee04a2a introduced the ignoreDeathEvent boolean in the DomainObjPrivate struct to ignore subsequent death events from libxl. But libxl already provides a mechanism to disable death events via libxl_evdisable_domain_death. This patch partially reverts commit fa30ee04a2a and instead uses libxl_evdisable_domain_death to disable subsequent death events when processing a shutdown event. |
Jim Fehlig <jfehlig@suse.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/23b51d7b8ec885e97a9277cf0a6c2833db4636e8 | 2021-10-29 |
| CVE-2021-4147_2.patch | libxl: Rename libxlShutdownThreadInfo struct An upcoming change will use the struct in a thread created to process death events. Rename libxlShutdownThreadInfo to libxlEventHandlerThreadInfo to reflect the more generic usage. |
Jim Fehlig <jfehlig@suse.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/a4e6fba069c0809b8b5dde5e9db62d2efd91b4a0 | 2021-11-24 |
| CVE-2021-4147_3.patch | libxl: Modify name of shutdown thread The current thread name 'ev-<domid>' is a bit terse. Change the name to 'shutdown-event-<domid>', allowing it to be distinguished between thread handling other event types. |
Jim Fehlig <jfehlig@suse.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/e4f7589a3ec285489618ca04c8c0230cc31f3d99 | 2021-11-24 |
| CVE-2021-4147_4.patch | libxl: Handle domain death events in a thread Similar to domain shutdown events, processing domain death events can be a lengthy process and we don't want to block the event handler while the operation completes. Move the death handling function to a thread. |
Jim Fehlig <jfehlig@suse.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/b9a5faea49b7412e26d7389af4c32fc2b3ee80e5 | 2021-11-24 |
| CVE-2021-4147_5.patch | libxl: Search for virDomainObj in event handler threads libxl can deliver events and invoke callbacks on any application thread calling into libxl. This can cause deadlock in the libvirt libxl driver Thread 19 (Thread 0x7f31411ec700 (LWP 14068) "libvirtd"): #0 0x00007f318520cc7d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f3185205ed5 in pthread_mutex_lock () from /lib64/libpthread.so.0 #2 0x00007f3189488015 in virMutexLock (m=<optimized out>) at ../../src/util/virthread.c:79 #3 0x00007f3189463f3b in virObjectLock (anyobj=<optimized out>) at ../../src/util/virobject.c:433 #4 0x00007f31894f2f41 in virDomainObjListSearchID (payload=0x7f317400a6d0, name=<optimized out>, data=0x7f31411eaeac) at ../../src/conf/virdomainobjlist.c:105 #5 0x00007f3189437ac5 in virHashSearch (ctable=0x7f3124025a30, iter=iter@entry=0x7f31894f2f30 <virDomainObjListSearchID>, data=data@entry=0x7f31411eaeac, name=name@entry=0x0) at ../../src/util/virhash.c:745 #6 0x00007f31894f3919 in virDomainObjListFindByID (doms=0x7f3124025430, id=<optimized out>) at ../../src/conf/virdomainobjlist.c:121 #7 0x00007f3152f292e5 in libxlDomainEventHandler (data=0x7f3124023d80, event=0x7f310c010ae0) at ../../src/libxl/libxl_domain.c:660 #8 0x00007f3152c6ff5d in egc_run_callbacks (egc=egc@entry=0x7f31411eaf50) at libxl_event.c:1427 #9 0x00007f3152c718bd in libxl__egc_cleanup (egc=0x7f31411eaf50) at libxl_event.c:1458 #10 libxl__ao_inprogress (ao=ao@entry=0x7f310c00b8a0, file=file@entry=0x7f3152cce987 "libxl_domain.c", line=line@entry=730, func=func@entry=0x7f3152ccf750 <__func__.22238> "libxl_domain_unpause") at libxl_event.c:2047 #11 0x00007f3152c8c5b8 in libxl_domain_unpause (ctx=0x7f3124015a40, domid=<optimized out>, ao_how=ao_how@entry=0x0) at libxl_domain.c:730 #12 0x00007f3152f2a584 in libxl_domain_unpause_0x041200 (domid=<optimized out>, ctx=<optimized out>) at /usr/include/libxl.h:1756 #13 libxlDomainStart (driver=driver@entry=0x7f3124023d80, vm=vm@entry=0x7f317400a6d0, start_paused=start_paused@entry=false, restore_fd=restore_fd@entry=-1, restore_ver=<optimized out>, restore_ver@entry=2) at ../../src/libxl/libxl_domain.c:1482 #14 0x00007f3152f2a6e3 in libxlDomainStartNew (driver=driver@entry=0x7f3124023d80, vm=vm@entry=0x7f317400a6d0, start_paused=start_paused@entry=false) at ../../src/libxl/libxl_domain.c:1545 #15 0x00007f3152f2a789 in libxlDomainShutdownHandleRestart (driver=0x7f3124023d80, vm=0x7f317400a6d0) at ../../src/libxl/libxl_domain.c:464 #16 0x00007f3152f2a9e4 in libxlDomainShutdownThread (opaque=<optimized out>) at ../../src/libxl/libxl_domain.c:559 #17 0x00007f3189487ee2 in virThreadHelper (data=<optimized out>) at ../../src/util/virthread.c:196 #18 0x00007f3185203539 in start_thread () from /lib64/libpthread.so.0 #19 0x00007f3184f3becf in clone () from /lib64/libc.so.6 Frame 16 runs a thread created to handle domain shutdown processing for domid 28712. In this case the event contained the reboot reason, so the old domain is destroyed and a new one is created by libxlDomainStart new. After starting the domain, it is unpaused by calling libxl_domain_unpause in frame 12. While the thread is running within libxl, libxl takes the opportunity to deliver a pending domain shutdown event for unrelated domid 28710. While searching for the associated virDomainObj by ID, a deadlock is encountered when attempting to lock the virDomainObj for domid 28712, which is already locked since this thread is processing its shutdown event. The deadlock can be avoided by moving the search for a virDomainObj associated with the event domid to the shutdown thread. The same is done for the death thread. |
Jim Fehlig <jfehlig@suse.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/5c5df5310f72be4878a71ace47074c54e0d1a27d | 2021-11-24 |
| CVE-2021-4147_6.patch | libxl: Protect access to libxlLogger files hash table The hash table of log file objects in libxlLogger is not protected against concurrent access. It is possible for one thread to remove an entry while another is updating it. Add a mutex to the libxlLogger object and lock it when accessing the files hash table. |
Jim Fehlig <jfehlig@suse.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/a7a03324d86e111f81687b5315b8f296dde84340 | 2021-11-18 |
| CVE-2022-0897.patch | nwfilter: fix crash when counting number of network filters The virNWFilterObjListNumOfNWFilters method iterates over the driver->nwfilters, accessing virNWFilterObj instances. As such it needs to be protected against concurrent modification of the driver->nwfilters object. This API allows unprivileged users to connect, so users with read-only access to libvirt can cause a denial of service crash if they are able to race with a call of virNWFilterUndefine. Since network filters are usually statically defined, this is considered a low severity problem. This is assigned CVE-2022-0897. |
Daniel P. Berrangé <berrange@redhat.com> | no | debian | https://gitlab.com/libvirt/libvirt/-/commit/a4947e8f63c3e6b7b067b444f3d6cf674c0d7f36 | 2022-03-08 |
| CVE-2024-1441.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. |
Martin Kletzander <mkletzan@redhat.com> | no | debian | https://gitlab.com/libvirt/libvirt/-/commit/c664015fe3a7bf59db26686e9ed69af011c6ebb8 | 2024-02-27 |
| CVE-2024-2496.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. |
Dmitry Frolov <frolov@swemel.ru> | no | debian | https://gitlab.com/libvirt/libvirt/-/commit/2ca94317ac642a70921947150ced8acc674ccdc8 | 2023-09-12 |
| CVE-2024-2494.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. |
Daniel P. Berrangé <berrange@redhat.com> | yes | debian upstream | https://gitlab.com/libvirt/libvirt/-/commit/8a3f8d957507c1f8223fdcf25a3ff885b15557f2 | 2024-03-15 |