Package: libvirt / 7.0.0-3+deb11u3

Metadata

Package Version Patches format
libvirt 7.0.0-3+deb11u3 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
backport/apparmor let image label setting loop over backing files.patch | (download)

src/security/security_apparmor.c | 39 27 + 12 - 0 !
1 file changed, 27 insertions(+), 12 deletions(-)

 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.

Fixes: https://gitlab.com/libvirt/libvirt/-/issues/118

backport/meson Fix cross building of dtrace probes.patch | (download)

meson.build | 1 1 + 0 - 0 !
src/meson.build | 4 2 + 2 - 0 !
src/qemu/meson.build | 4 2 + 2 - 0 !
3 files changed, 5 insertions(+), 4 deletions(-)

 meson: fix cross-building of dtrace probes
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

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

Signed-off-by: Helmut Grohne <helmut@subdivi.de>
backport/Fix reboot command for LXC containers.patch | (download)

src/lxc/lxc_controller.c | 18 11 + 7 - 0 !
1 file changed, 11 insertions(+), 7 deletions(-)

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

Fixes: https://gitlab.com/libvirt/libvirt/-/issues/237
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991773
Signed-off-by: Joachim Falk <joachim.falk@gmx.de>
revert/systemd Revert remote Add libvirtd dependency to virt gue.patch | (download)

src/remote/virt-guest-shutdown.target | 1 0 + 1 - 0 !
1 file changed, 1 deletion(-)

 systemd: revert "remote: add libvirtd dependency to
 virt-guest-shutdown.target" as it would reintroduce bug 955216

This reverts commit f035f53baa2e5dc00b8e866e594672a90b4cea78.

forward/Skip vircgrouptest.patch | (download)

tests/vircgrouptest.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 skip vircgrouptest

We don't have a mock for nodeGetCPUCount yet so we fail in a chroot
without sysfs mounted.

forward/Reduce udevadm settle timeout to 10 seconds.patch | (download)

src/util/virutil.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 reduce udevadm settle timeout to 10 seconds

This isn't a proper fix but it will make virt-manager at least start.

Closes: #663931

forward/Pass GPG_TTY env var to the ssh binary.patch | (download)

src/rpc/virnetsocket.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 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.

debian/Debianize libvirt guests.patch | (download)

tools/libvirt-guests.sh.in | 21 10 + 11 - 0 !
tools/libvirt-guests.sysconf | 4 2 + 2 - 0 !
2 files changed, 12 insertions(+), 13 deletions(-)

 debianize libvirt-guests

debian/Debianize libvirtd.patch | (download)

src/remote/libvirtd.sysconf | 30 24 + 6 - 0 !
1 file changed, 24 insertions(+), 6 deletions(-)

 debianize libvirtd


debian/Debianize systemd service files.patch | (download)

src/locking/virtlockd.service.in | 2 1 + 1 - 0 !
src/logging/virtlogd.service.in | 2 1 + 1 - 0 !
src/remote/libvirtd.service.in | 2 1 + 1 - 0 !
tools/libvirt-guests.service.in | 2 1 + 1 - 0 !
4 files changed, 4 insertions(+), 4 deletions(-)

 debianize systemd service files


debian/apparmor_profiles_local_include.patch | (download)

src/security/apparmor/libvirt-lxc | 3 3 + 0 - 0 !
src/security/apparmor/libvirt-qemu | 3 3 + 0 - 0 !
src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in | 1 1 + 0 - 0 !
src/security/apparmor/usr.sbin.libvirtd.in | 3 3 + 0 - 0 !
4 files changed, 10 insertions(+)

 apparmor_profiles_local_include

Include local apparmor profile

debian/Set defaults for zfs tools.patch | (download)

meson.build | 7 2 + 5 - 0 !
1 file changed, 2 insertions(+), 5 deletions(-)

 set defaults for zfs tools

so we don't have to build-depend on a program in contrib

debian/Revert m4 virt xdr rewrite XDR check.patch | (download)

meson.build | 2 0 + 2 - 0 !
1 file changed, 2 deletions(-)

 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.

debian/Use sensible editor by default.patch | (download)

tools/vsh.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 use sensible-editor by default

It is the reasonable default for Debian.

backport/vircgroup Fix virCgroupKillRecursive wrt nested controlle.patch | (download)

src/util/vircgroup.c | 25 23 + 2 - 0 !
src/util/vircgrouppriv.h | 1 0 + 1 - 0 !
src/util/vircgroupv1.c | 7 1 + 6 - 0 !
src/util/vircgroupv2.c | 7 1 + 6 - 0 !
4 files changed, 25 insertions(+), 15 deletions(-)

 vircgroup: fix vircgroupkillrecursive() wrt nested controllers
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

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.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
backport/tests Fix libxlxml2domconfigtest with latest xen.patch | (download)

tests/libxlmock.c | 11 11 + 0 - 0 !
tests/libxlxml2domconfigdata/basic-hvm.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/basic-pv.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/basic-pvh.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/cpu-shares-hvm.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/fullvirt-cpuid-legacy-nest.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/fullvirt-cpuid.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/max-eventchannels-hvm.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/max-gntframes-hvm.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/moredevs-hvm.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/multiple-ip.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/variable-clock-hvm.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/vnuma-hvm-legacy-nest.json | 2 1 + 1 - 0 !
tests/libxlxml2domconfigdata/vnuma-hvm.json | 2 1 + 1 - 0 !
15 files changed, 25 insertions(+), 14 deletions(-)

 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

backport/tests Fix libxlxml2domconfigtest.patch | (download)

tests/libxlmock.c | 15 15 + 0 - 0 !
tests/libxlxml2domconfigdata/vnuma-hvm.json | 5 5 + 0 - 0 !
2 files changed, 20 insertions(+)

 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
CVE 2021 3631.patch | (download)

src/security/security_selinux.c | 10 9 + 1 - 0 !
1 file changed, 9 insertions(+), 1 deletion(-)

 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.

CVE 2021 3667.patch | (download)

src/storage/storage_driver.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 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.

Fixes: 7aa0e8c0cb8
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1984318
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
CVE 2021 3975.patch | (download)

src/qemu/qemu_process.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

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

Suggested-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
libxl Fix domain shutdown.patch | (download)

src/libxl/libxl_domain.c | 120 57 + 63 - 0 !
1 file changed, 57 insertions(+), 63 deletions(-)

 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.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
CVE 2021 4147_1.patch | (download)

src/libxl/libxl_domain.c | 23 5 + 18 - 0 !
src/libxl/libxl_domain.h | 3 0 + 3 - 0 !
2 files changed, 5 insertions(+), 21 deletions(-)

 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.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
CVE 2021 4147_2.patch | (download)

src/libxl/libxl_domain.c | 10 5 + 5 - 0 !
1 file changed, 5 insertions(+), 5 deletions(-)

 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.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
CVE 2021 4147_3.patch | (download)

src/libxl/libxl_domain.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 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.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
CVE 2021 4147_4.patch | (download)

src/libxl/libxl_domain.c | 67 47 + 20 - 0 !
1 file changed, 47 insertions(+), 20 deletions(-)

 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.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
CVE 2021 4147_5.patch | (download)

src/libxl/libxl_domain.c | 35 18 + 17 - 0 !
1 file changed, 18 insertions(+), 17 deletions(-)

 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.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
CVE 2021 4147_6.patch | (download)

src/libxl/libxl_logger.c | 14 14 + 0 - 0 !
1 file changed, 14 insertions(+)

 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.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
CVE 2022 0897.patch | (download)

src/nwfilter/nwfilter_driver.c | 8 6 + 2 - 0 !
1 file changed, 6 insertions(+), 2 deletions(-)

 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.

CVE 2024 1441.patch | (download)

src/interface/interface_backend_udev.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 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.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reported-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Fixes: 5a33366f5c0b18c93d161bd144f9f079de4ac8ca
Fixes: d6064e2759a24e0802f363e3a810dc5a7d7ebb15
CVE 2024 2496.patch | (download)

src/interface/interface_backend_udev.c | 26 19 + 7 - 0 !
1 file changed, 19 insertions(+), 7 deletions(-)

 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.

Signed-off-by: Dmitry Frolov <frolov@swemel.ru>
CVE 2024 2494.patch | (download)

src/remote/remote_daemon_dispatch.c | 65 65 + 0 - 0 !
src/rpc/gendispatch.pl | 5 5 + 0 - 0 !
2 files changed, 70 insertions(+)

 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.