Debian Patches
Status for libvirt/11.3.0-3+deb13u3
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| backport/qemuProcessStartWithMemoryState-Don-t-setup-qemu-for-inco.patch | qemuProcessStartWithMemoryState: Don't setup qemu for incoming migration when reverting internal snapshot The memory/device state of the VM for an internal snapshot is restored by qemu itself via a QMP command and is taken from the qcow2 image, thus we don't actually do any form of incoming migration. Commit 5b324c0a739fe00 which refactored the setup of the incoming migration state didn't take the above into account and inadvertently caused that qemu is being started with '-incoming defer' also when libvirt would want to revert an internal snapshot. Now when qemu expects incoming migration it doesn't activate the block backends as that would cause locking problems and image inconsistency, but also doesn't allow the use of the images. Since the block backends are not activated qemu then thinks that they don't actually support internal snapshots and reports: error: operation failed: load of internal snapshot 'foo1' job failed: Device 'libvirt-1-format' is writable but does not support snapshots Due to the above bug it's not possible to revert to internal snapshots in libvirt-11.2 and libvirt-11.3. (cherry picked from commit 889d2ae289cd95d612575ebc7a4e111ac33b0939) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/889d2ae289cd95d612575ebc7a4e111ac33b0939 | 2025-05-13 |
| backport/qemu-Be-more-forgiving-when-acquiring-QUERY-job-when-form.patch | qemu: Be more forgiving when acquiring QUERY job when formatting domain XML In my previous commit of v11.0.0-rc1~115 I've made QEMU driver implementation for virDomainGetXMLDesc() (qemuDomainGetXMLDesc()) acquire QERY job. See its commit message for more info. But this unfortunately broke apps witch fetch domain XML for incoming migration (like virt-manager). The reason is that for incoming migration the VIR_ASYNC_JOB_MIGRATION_IN async job is set, but the mask of allowed synchronous jobs is empty (because QEMU can't talk on monitor really). This makes virDomainObjBeginJob() fail which in turn makes qemuDomainGetXMLDesc() fail too. It makes sense for qemuDomainGetXMLDesc() to acquire the job (e.g. so that it's coherent with another thread that might be in the middle of a MODIFY job). But failure to dump XML may be treated as broken daemon (e.g. virt-manager does so). Therefore, still try to acquire the QUERY job (if job mask permits it) but, do not treat failure as an error. (cherry picked from commit 441c23a7e626c13e6df1946303a0bc0a84180d1c) |
Michal Privoznik <mprivozn@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/441c23a7e626c13e6df1946303a0bc0a84180d1c | 2025-06-16 | |
| backport/tlscert-Don-t-force-keyEncipherment-for-ECDSA-and-ECDH.patch | tlscert: Don't force 'keyEncipherment' for ECDSA and ECDH Per RFC8813 [1] which amends RFC5580 [2] ECDSA, ECDH, and ECMQV algorithms must not have 'keyEncipherment' present, but our code did check it. Add exemption for known algorithms which don't use it. [1] https://datatracker.ietf.org/doc/rfc8813/ [2] https://datatracker.ietf.org/doc/rfc5480 (cherry picked from commit 11867b0224a2b8dc34755ff0ace446b6842df1c1) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/11867b0224a2b8dc34755ff0ace446b6842df1c1 | 2025-06-17 |
| backport/tls-Don-t-require-keyEncipherment-to-be-enabled-altoghthe.patch | tls: Don't require 'keyEncipherment' to be enabled altoghther Key encipherment is required only for RSA key exchange algorithm. With TLS 1.3 this is not even used as RSA is used only for authentication. Since we can't really check when it's required ahead of time drop the check completely. GnuTLS will moan if it will not be able to use RSA key exchange. In commit 11867b0224a2 I tried to relax the check for some eliptic curve algorithm that explicitly forbid it. Based on the above the proper solution is to completely remove it. (cherry picked from commit 8cecd3249e5fa5478a7c53567971b4d969274ea3) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/8cecd3249e5fa5478a7c53567971b4d969274ea3 | 2025-06-30 |
| backport/tests-virnettls-test-Drop-use-of-GNUTLS_KEY_KEY_ENCIPHERM.patch | tests: virnettls*test: Drop use of GNUTLS_KEY_KEY_ENCIPHERMENT It's not needed with TLS 1.3 any more. (cherry picked from commit e67952b0e612c9ad3c3eec8bb692589602953ee8) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/e67952b0e612c9ad3c3eec8bb692589602953ee8 | 2025-07-01 |
| backport/daemon-Drop-log-level-of-VIR_ERR_NO_SUPPORT-to-debug.patch | daemon: Drop log level of VIR_ERR_NO_SUPPORT to debug The error code signals that the API the user called is not supported by the driver. This can happen with some hypervisor drivers which don't have everything implemented yet. There's no point in spamming the log with it. (cherry picked from commit 37a1bd945899308d1c071bb885e5d1d9529d6b85) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/37a1bd945899308d1c071bb885e5d1d9529d6b85 | 2025-08-26 |
| backport/qemu-capabilities-Check-if-cpuModels-is-not-NULL-before-t.patch | qemu: capabilities: Check if cpuModels is not NULL before trying to dereference it accel->cpuModels field might be NULL if QEMU does not return CPU models. The following backtrace is observed in such cases: 0 virQEMUCapsProbeQMPCPUDefinitions (qemuCaps=qemuCaps@entry=0x7f1890003ae0, accel=accel@entry=0x7f1890003c10, mon=mon@entry=0x7f1890005270) at ../src/qemu/qemu_capabilities.c:3091 1 0x00007f18b42fa7b1 in virQEMUCapsInitQMPMonitor (qemuCaps=qemuCaps@entry=0x7f1890003ae0, mon=0x7f1890005270) at ../src/qemu/qemu_capabilities.c:5746 2 0x00007f18b42fafaf in virQEMUCapsInitQMPSingle (qemuCaps=qemuCaps@entry=0x7f1890003ae0, libDir=libDir@entry=0x7f186c1e70f0 "/var/lib/libvirt/qemu", runUid=runUid@entry=955, runGid=runGid@entry=955, onlyTCG=onlyTCG@entry=false) at ../src/qemu/qemu_capabilities.c:5832 3 0x00007f18b42fb1a5 in virQEMUCapsInitQMP (qemuCaps=0x7f1890003ae0, libDir=0x7f186c1e70f0 "/var/lib/libvirt/qemu", runUid=955, runGid=955) at ../src/qemu/qemu_capabilities.c:5848 4 virQEMUCapsNewForBinaryInternal (hostArch=VIR_ARCH_X86_64, binary=binary@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha", libDir=0x7f186c1e70f0 "/var/lib/libvirt/qemu", runUid=955, runGid=955, hostCPUSignature=0x7f186c1e9f20 "AuthenticAMD, AMD Ryzen 9 7950X 16-Core Processor, family: 25, model: 97, stepping: 2", microcodeVersion=174068233, kernelVersion=0x7f186c194200 "6.14.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 29 May 2025 21:42:15 +0000", cpuData=0x7f186c1ea490) at ../src/qemu/qemu_capabilities.c:5907 5 0x00007f18b42fb4c9 in virQEMUCapsNewData (binary=0x7f1868002fc0 "/usr/bin/qemu-system-alpha", privData=0x7f186c194280) at ../src/qemu/qemu_capabilities.c:5942 6 0x00007f18bd42d302 in virFileCacheNewData (cache=0x7f186c193730, name=0x7f1868002fc0 "/usr/bin/qemu-system-alpha") at ../src/util/virfilecache.c:206 7 virFileCacheValidate (cache=cache@entry=0x7f186c193730, name=name@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha", data=data@entry=0x7f18b67c37c0) at ../src/util/virfilecache.c:269 8 0x00007f18bd42d5b8 in virFileCacheLookup (cache=cache@entry=0x7f186c193730, name=name@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha") at ../src/util/virfilecache.c:301 9 0x00007f18b42fb679 in virQEMUCapsCacheLookup (cache=cache@entry=0x7f186c193730, binary=binary@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha") at ../src/qemu/qemu_capabilities.c:6036 10 0x00007f18b42fb785 in virQEMUCapsInitGuest (caps=<optimized out>, cache=<optimized out>, hostarch=VIR_ARCH_X86_64, guestarch=VIR_ARCH_ALPHA) at ../src/qemu/qemu_capabilities.c:1037 11 virQEMUCapsInit (cache=0x7f186c193730) at ../src/qemu/qemu_capabilities.c:1229 12 0x00007f18b431d311 in virQEMUDriverCreateCapabilities (driver=driver@entry=0x7f186c01f410) at ../src/qemu/qemu_conf.c:1553 13 0x00007f18b431d663 in virQEMUDriverGetCapabilities (driver=0x7f186c01f410, refresh=<optimized out>) at ../src/qemu/qemu_conf.c:1623 14 0x00007f18b435e3e4 in qemuConnectGetVersion (conn=<optimized out>, version=0x7f18b67c39b0) at ../src/qemu/qemu_driver.c:1492 15 0x00007f18bd69c5e8 in virConnectGetVersion (conn=0x55bc5f4cda20, hvVer=hvVer@entry=0x7f18b67c39b0) at ../src/libvirt-host.c:201 16 0x000055bc34ef3627 in remoteDispatchConnectGetVersion (server=0x55bc5f4b93f0, msg=0x55bc5f4cdf60, client=0x55bc5f4c66d0, rerr=0x7f18b67c3a80, ret=0x55bc5f4b8670) at src/remote/remote_daemon_dispatch_stubs.h:1265 17 remoteDispatchConnectGetVersionHelper (server=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60, rerr=0x7f18b67c3a80, args=0x0, ret=0x55bc5f4b8670) at src/remote/remote_daemon_dispatch_stubs.h:1247 18 0x00007f18bd5506da in virNetServerProgramDispatchCall (prog=0x55bc5f4cae90, server=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60) at ../src/rpc/virnetserverprogram.c:423 19 virNetServerProgramDispatch (prog=0x55bc5f4cae90, server=server@entry=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60) at ../src/rpc/virnetserverprogram.c:299 20 0x00007f18bd556c32 in virNetServerProcessMsg (srv=srv@entry=0x55bc5f4b93f0, client=<optimized out>, prog=<optimized out>, msg=<optimized out>) at ../src/rpc/virnetserver.c:135 21 0x00007f18bd556f77 in virNetServerHandleJob (jobOpaque=0x55bc5f4d2bb0, opaque=0x55bc5f4b93f0) at ../src/rpc/virnetserver.c:155 22 0x00007f18bd47dd19 in virThreadPoolWorker (opaque=<optimized out>) at ../src/util/virthreadpool.c:164 23 0x00007f18bd47d253 in virThreadHelper (data=0x55bc5f4b7810) at ../src/util/virthread.c:256 24 0x00007f18bce117eb in start_thread (arg=<optimized out>) at pthread_create.c:448 25 0x00007f18bce9518c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 (cherry picked from commit e7239c619fcaf35b8b605ce07c5d5b15351b3a62) |
anonymix007 <48598263+anonymix007@users.noreply.github.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/e7239c619fcaf35b8b605ce07c5d5b15351b3a62 | 2025-06-04 |
| backport/conf-Add-virDomainDefIDsParseString.patch | conf: Add virDomainDefIDsParseString This function performs only parsing with the underlying virDomainDefParseIDs() function to get needed metadata for any ACL checks, but nothing else to avoid extraneous allocations and any parser-induced DoS over ACL-forbidden connections. (cherry picked from commit e6de1e43ab6e907225b8f9bcea3772231908717e) CVE-2025-12784 |
Martin Kletzander <mkletzan@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/e6de1e43ab6e907225b8f9bcea3772231908717e | 2025-11-06 |
| backport/bhyve-Check-ACLs-before-parsing-the-whole-domain-XML.patch | bhyve: Check ACLs before parsing the whole domain XML Utilise the new virDomainDefIDsParseString() for that. (cherry picked from commit b45f10bc0a2f30ccdbf2cb55da2e4f85b3ebfb23) |
Martin Kletzander <mkletzan@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/b45f10bc0a2f30ccdbf2cb55da2e4f85b3ebfb23 | 2025-11-06 |
| backport/libxl-Check-ACLs-before-parsing-the-whole-domain-XML.patch | libxl: Check ACLs before parsing the whole domain XML Utilise the new virDomainDefIDsParseString() for that. (cherry picked from commit a1f48bca077e2f3377f29d746efd4310b8a2910f) |
Martin Kletzander <mkletzan@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/a1f48bca077e2f3377f29d746efd4310b8a2910f | 2025-11-06 |
| backport/lxc-Check-ACLs-before-parsing-the-whole-domain-XML.patch | lxc: Check ACLs before parsing the whole domain XML Utilise the new virDomainDefIDsParseString() for that. (cherry picked from commit a6dcfee896f67bb8bdfdbb0b406ac7649fbb4c0f) |
Martin Kletzander <mkletzan@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/a6dcfee896f67bb8bdfdbb0b406ac7649fbb4c0f | 2025-11-06 |
| backport/vz-Check-ACLs-before-parsing-the-whole-domain-XML.patch | vz: Check ACLs before parsing the whole domain XML Utilise the new virDomainDefIDsParseString() for that. (cherry picked from commit 7285c10a7e70c430f85af7a2b3954892ab3c6d6b) |
Martin Kletzander <mkletzan@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/7285c10a7e70c430f85af7a2b3954892ab3c6d6b | 2025-11-06 |
| backport/ch-Check-ACLs-before-parsing-the-whole-domain-XML.patch | ch: Check ACLs before parsing the whole domain XML Utilise the new virDomainDefIDsParseString() for that. This is one of the more complex ones since there is also a function that reads relevant metadata from a save image XML. In order not to extract the parsing out of the function (and make the function basically trivial and all callers more complex) add a callback to the function which will be used to check the ACLs. And since this function is called in APIs that perform ACL checks both with and without flags, add two of them for good measure. (cherry picked from commit eb4322dfe8fff544d6dac01b2748c20f78f00d69) |
Martin Kletzander <mkletzan@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/eb4322dfe8fff544d6dac01b2748c20f78f00d69 | 2025-11-06 |
| backport/qemu-Check-ACLs-before-parsing-the-whole-domain-XML.patch | qemu: Check ACLs before parsing the whole domain XML Utilise the new virDomainDefIDsParseString() for that. This is one of the more complex ones since there is also a function that reads relevant metadata from a save image XML. In order _not_ to extract the parsing out of the function (and make the function basically trivial and all callers more complex) add a callback to the function which will be used to check the ACLs. (cherry picked from commit 2a326c415a7e1cdd49989cc7e46b88d9ca90dd97) |
Martin Kletzander <mkletzan@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/2a326c415a7e1cdd49989cc7e46b88d9ca90dd97 | 2025-11-06 |
| backport/qemu-snapshot-Set-umask-for-qemu-img-when-creating-extern.patch | qemu: snapshot: Set umask for 'qemu-img' when creating external inactive snapshots External inactive snapshots are created by invoking 'qemu-img' which creates the file. Currently qemu-img creates image with mode 644 based on default umask as libvirt doesn't set any. Having a world-readable image is obviously wrong so set the umask to 077 to have the file readable only by the owner. (cherry picked from commit a379327d8abcde8ac8d3e16fe5e4ba6f790d767a) CVE-2025-13193 |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/a379327d8abcde8ac8d3e16fe5e4ba6f790d767a | 2025-11-12 |
| backport/qemuxmlconftest-Improve-coverage-of-disk-detect-zeroes-te.patch | qemuxmlconftest: Improve coverage of 'disk-detect-zeroes' test case Add test cases for all three options 'off'/'on'/'unmap' as well as add backing store for each image to show how the configuration behaves. (cherry picked from commit 312be5eb9acfc3bbf164583ed7ed1d3b89698c5a) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/312be5eb9acfc3bbf164583ed7ed1d3b89698c5a | 2025-11-14 |
| backport/qemuDomainPrepareDiskSourceData-Setup-detect_zeroes-for-a.patch | qemuDomainPrepareDiskSourceData: Setup 'detect_zeroes' for all layers While it may seem that zero detection is pointless for backing chain layers other than the top one, which is usually the only one gettin written to, with block operations such as active-layer commit the non-top layer may become active, in which case the VM wouldn't be configured in accordance to the XML any more. Similarly with snapshots a new image is introduced which would not get zero detection enabled, but next start of the VM would enable it. Fix this by propagating the zero detection setting for all layers. This problem partially addresses one of the issues reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120389 (cherry picked from commit 475ed7075d400347f7e1b0f49ce1d1a39798ef99) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/475ed7075d400347f7e1b0f49ce1d1a39798ef99 | 2025-11-14 |
| backport/qemuMonitorJSONMigrate-Drop-detach-QMP-option.patch | qemuMonitorJSONMigrate: Drop 'detach' QMP option The argument was always ignored by qemu [1], as of qemu-10.1 it will be deprecated. As it was always unused/ignored we can drop it without any extra logic. [1] qemu docs state: 3. The user Monitor's "detach" argument is invalid in QMP and should not be used. (cherry picked from commit 17e170a137911837867feb680ed5d5d132133621) |
Peter Krempa <pkrempa@redhat.com> | not-needed | debian | https://gitlab.com/libvirt/libvirt/-/commits/17e170a137911837867feb680ed5d5d132133621 | 2025-05-21 |
| backport/remote-Fix-integer-overflow-in-RPC-handler-for-virNodeGet.patch | remote: Fix integer overflow in RPC handler for virNodeGetFreePages (CVE-2026-18917) CVE-2026-18917 The RPC handler 'remoteDispatchNodeGetFreePages' multiplies the 'npages' argument with the 'cellcount' argument passed to 'virNodeGetFreePages', both of which are declared as 'unsigned int' to both do an RPC limit check against the 'REMOTE_NODE_MAX_CELLS' constant and then to allocate the memory to hold the result from the actual hypervisor driver. Since both the values are 'unsigned int' the product is also unsigned int so big enough numbers can overflow, both passing the check and also allocating not enough memory for the result. The hypervisor driver assumes that the passed buffer is large enough and overwrites memory. When this happens the the hypervisor daemon crashes. This can be triggered e.g. by passing 1023 and 4198405 as values which multiply to 1019 after wrapping to 32 bit unsigned value. Use the VIR_INT_MULTIPLY_OVERFLOW macro in the check to avoid the issue the same way as we do for other APIs doing multiplication of arguments to determine amount of required memory. (cherry picked from commit 5a62cbf2907d4590283597b46da9c0f41e7b4d4f) |
Peter Krempa <pkrempa@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/5a62cbf2907d4590283597b46da9c0f41e7b4d4f | 2026-08-12 | |
| backport/conf-reject-line-breaks-in-DNS-TXT-record-values.patch | conf: reject line breaks in DNS TXT record values The network XML schema exposes typed DNS records through the <dns><txt> element. The TXT value attribute accepts XML numeric character references, including (LF) and (CR), which survive attribute-value normalization. The network driver later writes the value verbatim into dnsmasq's line-oriented configuration file as a txt-record= line, so an embedded line break ends that directive and starts a new one under attacker control. This is a real boundary where a management layer permits editing typed DNS records while withholding the raw <dnsmasq:options> read-write access to the libvirt socket is already root-equivalent, so for the default deployment this is schema-correctness hardening. Add a helper that rejects LF and CR and call it for the TXT value during XML parsing. CVE-2026-61477 (cherry picked from commit d44836a1dc6771ac22f69755fc69bf730f0eec87) |
Michael Bommarito <michael.bommarito@gmail.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/d44836a1dc6771ac22f69755fc69bf730f0eec87 | 2026-07-10 | |
| backport/conf-reject-line-breaks-in-DNS-SRV-domain-and-target.patch | conf: reject line breaks in DNS SRV domain and target The <dns><srv> domain and target attributes flow through the same dnsmasq configuration emitter as TXT values, written into srv-host= lines. Like the TXT value they accept XML numeric character references for LF and CR and are not otherwise constrained, unlike service and protocol which already have allow-lists. An embedded line break ends the srv-host= directive and begins a new one. Reject LF and CR in the SRV domain and target during XML parsing, reusing the helper added for TXT values. CVE-2026-61477 (cherry picked from commit 289ffa796d737a79a4c05d07232ebd75def9a12a) |
Michael Bommarito <michael.bommarito@gmail.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/289ffa796d737a79a4c05d07232ebd75def9a12a | 2026-07-10 | |
| backport/network-reject-line-breaks-before-writing-dnsmasq-DNS-con.patch | network: reject line breaks before writing dnsmasq DNS config The parser now rejects line breaks in typed DNS TXT and SRV fields, but the dnsmasq configuration emitter is the actual trust boundary: any future parser gap, or a value reaching the emitter by another path, would again let a typed DNS field inject an arbitrary dnsmasq directive. Add a defensive check in networkDnsmasqConfContents() that rejects LF and CR in every typed DNS string immediately before it is written to the line-based configuration file. This sits behind the parser checks and keeps the emitter correct on its own. The raw <dnsmasq:options> namespace is intentionally left untouched: it is the documented escape hatch for arbitrary dnsmasq options, and sanitizing it would be a separate, deliberate behavior change. CVE-2026-61477 (cherry picked from commit cb8974b923e3c40cde96f0c7bceaa638f7f9c72b) |
Michael Bommarito <michael.bommarito@gmail.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/cb8974b923e3c40cde96f0c7bceaa638f7f9c72b | 2026-07-10 | |
| backport/tests-cover-line-break-rejection-in-DNS-TXT-and-SRV-recor.patch | tests: cover line-break rejection in DNS TXT and SRV records Add negative tests that feed XML numeric character references for LF ( ) and CR ( ) into the DNS TXT value and SRV domain/target attributes, covering both the network XML parse path and the update API. Literal newlines are insufficient because XML parsers normalize raw attribute whitespace to spaces; the numeric references are what survive to the configuration emitter. CVE-2026-61477 (cherry picked from commit 3cfc77963b512d809348fca07f97fe924fac9a05) |
Michael Bommarito <michael.bommarito@gmail.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/3cfc77963b512d809348fca07f97fe924fac9a05 | 2026-07-10 | |
| backport/src-fix-crash-searching-for-XML-context-string-on-errors.patch | src: fix crash searching for XML context string on errors When we have an XML parse error, libxml2 invokes a callback that receives pointers to the start of the document being parsed and the location where the error was triggered. In the case of a document that contains 100's of empty lines (ie a sequence of newlines), at some point libxml2 will advance the base pointer discarding the useful context. Thus when catchXMLError then searches backwards to discard empty lines and look for the context element, it will eventually get to the start of the string. When this happens the virBuffer that holds the context string ends up empty and then catchXMLError will dereference a NULL pointer. In almost all cases, the APIs which accept XML documents from the user are behind the primary read-write socket, however, the CPU baseline API is exposed to the read-only socket. Thus an unprivileged user can trigger a denial of service by crashing the libvirt daemons with a malicious XML document. Check for this empty string condition and skip inclusion of the XML document context in the error message. (cherry picked from commit 68da70aae766c6271b8d3b466374d3cc7d1a8afb) |
"Daniel P. Berrangé" <berrange@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/68da70aae766c6271b8d3b466374d3cc7d1a8afb | 2026-07-14 | |
| backport/util-virFileChownFiles-do-not-follow-symlinks.patch | util: virFileChownFiles: do not follow symlinks virFileChownFiles() selected entries with virFileIsRegular() (stat(), follows symlinks) and changed ownership with chown() (follows symlinks). A component that owns the target directory at a lower privilege (e.g. the swtpm/tss state directory) can plant a symlink to an arbitrary regular file and have the root caller chown that file. Use lstat() to skip non-regular entries and fchownat(..., AT_SYMLINK_NOFOLLOW) so a symlink final component is never followed. [DB: use g_lstat instead of stat; use lchown instead of fchownat for portability; added comment] (cherry picked from commit 801160fd414ca2cc402bc01ead09b7ed4c3b8f5b) |
HE WEI（ギカク） <skyexpoc@gmail.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/801160fd414ca2cc402bc01ead09b7ed4c3b8f5b | 2026-07-28 | |
| backport/storage-create-images-with-a-private-umask-during-qemu-im.patch | storage: create images with a private umask during qemu-img create/convert On the local (non-NETFS) path virStorageBackendCreateExecCommand() ran qemu-img with umask 0, so the destination image was created world-readable (0644) and the full source disk was written into it before libvirt tightened the mode with a later chmod(). This is the same class as CVE-2025-13193; apply the same fix by setting a 0077 umask so qemu-img creates the file private from the start. [DB: merged the two virCommandSetUmask to one] (cherry picked from commit 69335a484768d550854da1133d5490074695e825) |
HE WEI（ギカク） <skyexpoc@gmail.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commits/69335a484768d550854da1133d5490074695e825 | 2026-07-28 | |
| debian/Debianize-libvirt-guests.patch | Debianize libvirt-guests | Laurent Léonard <laurent@open-minds.org> | not-needed | 2010-12-09 | ||
| 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/Drop-inter-package-Also-lines-from-libvirtd.service.patch | Drop inter-package Also= lines from libvirtd.service systemctl handles these lines gracefully even when the corresponding unit is not present, e.g. because the daemon-lock package is not installed, but deb-systemd-helper doesn't. As a temporary workaround until this limitation is addressed, drop the lines triggering the failure. Note that we would technically only need to drop the reference to virtlockd.socket, since the daemon-log package is a hard dependency of the daemon package and thus we know that virtlogd.socket is always going to be present, but being more aggressive for consistency's sake seems preferable. |
Andrea Bolognani <eof@kiyuko.org> | not-needed | debian | 2025-04-13 |
All known versions for source package 'libvirt'
- 12.8.0-1 (sid)
- 12.7.0-1 (forky)
- 11.3.0-3+deb13u3 (trixie)
- 11.3.0-2~bpo12+1 (bookworm-backports)
- 9.0.0-4+deb12u2 (bookworm)