From c065481eaab9595a4f9b25c7b9729883568c5f95 Mon Sep 17 00:00:00 2001 From: Jiri Denemark Date: Fri, 23 Jan 2026 14:12:47 +0100 Subject: [PATCH] libvirt-11.10.0-3.el10 - util: json: Increase JSON nesting limit when parsing to 300 (RHEL-135181) - virjsontest: Add test for nesting depth (RHEL-135181) - qemuSecurityMoveImageMetadata: Move seclabels only to virStorageSource of same type (RHEL-114412) - esx: Allow connecting to IPv6 server (RHEL-138300) Resolves: RHEL-114412, RHEL-135181, RHEL-138300 --- ...-esx-Allow-connecting-to-IPv6-server.patch | 43 ++++++++++++++ ...nly-to-virStorageSource-of-same-type.patch | 56 +++++++++++++++++++ ...ON-nesting-limit-when-parsing-to-300.patch | 50 +++++++++++++++++ ...rjsontest-Add-test-for-nesting-depth.patch | 45 +++++++++++++++ libvirt.spec | 12 +++- 5 files changed, 205 insertions(+), 1 deletion(-) create mode 100644 libvirt-esx-Allow-connecting-to-IPv6-server.patch create mode 100644 libvirt-qemuSecurityMoveImageMetadata-Move-seclabels-only-to-virStorageSource-of-same-type.patch create mode 100644 libvirt-util-json-Increase-JSON-nesting-limit-when-parsing-to-300.patch create mode 100644 libvirt-virjsontest-Add-test-for-nesting-depth.patch diff --git a/libvirt-esx-Allow-connecting-to-IPv6-server.patch b/libvirt-esx-Allow-connecting-to-IPv6-server.patch new file mode 100644 index 0000000..232a8cc --- /dev/null +++ b/libvirt-esx-Allow-connecting-to-IPv6-server.patch @@ -0,0 +1,43 @@ +From 16276aad5c682651e2a5aabe7d5a7258dda251c1 Mon Sep 17 00:00:00 2001 +Message-ID: <16276aad5c682651e2a5aabe7d5a7258dda251c1.1769173967.git.jdenemar@redhat.com> +From: Michal Privoznik +Date: Tue, 20 Jan 2026 10:08:29 +0100 +Subject: [PATCH] esx: Allow connecting to IPv6 server +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +When connecting to a VMWare server, the hostname from URI is +resolved using esxUtil_ResolveHostname() which in turn calls +getaddrinfo(). But in the hints argument, we restrict the return +address to be IPv4 (AF_INET) which obviously fails if the address +to resolve is an IPv6 address. Set the hint to AF_UNSPEC which +allows both IPv4 and IPv6. While at it, also allow IPv4 addresses +mapped in IPv6 by setting AI_V4MAPPED flag. + +Resolves: https://issues.redhat.com/browse/RHEL-138300 +Signed-off-by: Michal Privoznik +Reviewed-by: Daniel P. Berrangé +(cherry picked from commit 845210011a9ffd9d17e30c51cbc81ba67c5d3166) +Signed-off-by: Michal Privoznik +--- + src/esx/esx_util.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/src/esx/esx_util.c b/src/esx/esx_util.c +index 7ee0e5f7c0..12a34a2275 100644 +--- a/src/esx/esx_util.c ++++ b/src/esx/esx_util.c +@@ -280,8 +280,8 @@ esxUtil_ResolveHostname(const char *hostname, char **ipAddress) + int errcode; + g_autofree char *address = NULL; + +- hints.ai_flags = AI_ADDRCONFIG; +- hints.ai_family = AF_INET; ++ hints.ai_flags = AI_ADDRCONFIG | AI_V4MAPPED; ++ hints.ai_family = AF_UNSPEC; + hints.ai_socktype = SOCK_STREAM; + hints.ai_protocol = 0; + +-- +2.52.0 diff --git a/libvirt-qemuSecurityMoveImageMetadata-Move-seclabels-only-to-virStorageSource-of-same-type.patch b/libvirt-qemuSecurityMoveImageMetadata-Move-seclabels-only-to-virStorageSource-of-same-type.patch new file mode 100644 index 0000000..6be8545 --- /dev/null +++ b/libvirt-qemuSecurityMoveImageMetadata-Move-seclabels-only-to-virStorageSource-of-same-type.patch @@ -0,0 +1,56 @@ +From 5a7cc07af8355ae117d04d357bd8b694fc2af091 Mon Sep 17 00:00:00 2001 +Message-ID: <5a7cc07af8355ae117d04d357bd8b694fc2af091.1769173967.git.jdenemar@redhat.com> +From: Peter Krempa +Date: Mon, 12 Jan 2026 10:54:38 +0100 +Subject: [PATCH] qemuSecurityMoveImageMetadata: Move seclabels only to + virStorageSource of same type + +The concept of moving a seclabel is used e.g. when a new image is +introduced to the backing chain (or one of the existing ones becomes +active during block commit). What it does is that it moves the metedata +remembering the original seclabel to the new image. + +That idea works reasonably well if both the original and new image are +of same type e.g. a file, where they have comparable seclabel. + +It breaks down though when you e.g. create a snapshot stored in a 'file' +on top of a disk originally backed by a 'block' storage source, since +the seclabels differ quite siginificantly. + +This patch restricts the seclabel move in qemuSecurityMoveImageMetadata +to happen only if the storage sources are of same type to avoid the +issue. This means that the seclabels will not be remebered and will be +restored to the default but it's better than to transfer wrong labels. + +Resolves: https://issues.redhat.com/browse/RHEL-114412 + +Signed-off-by: Peter Krempa +Reviewed-by: Michal Privoznik +(cherry picked from commit 37d51c0d27692a245d7a5eeeef57748e7574de4b) +--- + src/qemu/qemu_security.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c +index 6bb0f9170d..84cb981a96 100644 +--- a/src/qemu/qemu_security.c ++++ b/src/qemu/qemu_security.c +@@ -201,6 +201,16 @@ qemuSecurityMoveImageMetadata(virQEMUDriver *driver, + if (qemuDomainNamespaceEnabled(vm, QEMU_DOMAIN_NS_MOUNT)) + pid = vm->pid; + ++ /* Moving seclabel metadata makes sense only when 'src' and 'dst' are of ++ * the same type. Otherwise 'dst' could end up with a seclabel that doesn't ++ * make sense for it (e.g. a seclabel originating from a block device /dev ++ * node moved to a file), once the seclabels are restored for it */ ++ if (src && dst && src->type != dst->type) { ++ VIR_DEBUG("dropping security label metadata instead of moving it from '%s' to '%s' due to type mismatch", ++ NULLSTR(src->path), NULLSTR(dst->path)); ++ dst = NULL; ++ } ++ + return virSecurityManagerMoveImageMetadata(driver->securityManager, + cfg->sharedFilesystems, + pid, src, dst); +-- +2.52.0 diff --git a/libvirt-util-json-Increase-JSON-nesting-limit-when-parsing-to-300.patch b/libvirt-util-json-Increase-JSON-nesting-limit-when-parsing-to-300.patch new file mode 100644 index 0000000..0f27114 --- /dev/null +++ b/libvirt-util-json-Increase-JSON-nesting-limit-when-parsing-to-300.patch @@ -0,0 +1,50 @@ +From e78a5a3559bee1bca42f8edde91e836b301876dc Mon Sep 17 00:00:00 2001 +Message-ID: +From: Peter Krempa +Date: Thu, 11 Dec 2025 09:39:03 +0100 +Subject: [PATCH] util: json: Increase JSON nesting limit when parsing to 300 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The default in json-c is 32 which is too low to accomodate the 200 +snapshot layers we supported historically in the qemu driver (200 is +picked based on the 256 layer limit in libxml). + +The response to 'query-block' is otherwise too low and we fail to start +the VM when there's around 26 images in a backing chain. + +'json_tokener_new_ex' is supported since json-c 0.11 and we require at +least 0.14. + +Signed-off-by: Peter Krempa +Reviewed-by: Ján Tomko +(cherry picked from commit b49d41b7e9eb983fdfbf70c91c2a27a995af3987) +https://issues.redhat.com/browse/RHEL-135181 +--- + src/util/virjson.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +diff --git a/src/util/virjson.c b/src/util/virjson.c +index a799707c16..454bd657be 100644 +--- a/src/util/virjson.c ++++ b/src/util/virjson.c +@@ -1466,7 +1466,15 @@ virJSONValueFromString(const char *jsonstring) + + VIR_DEBUG("string=%s", jsonstring); + +- tok = json_tokener_new(); ++ /* When creating the tokener we need to specify the limit of the nesting ++ * depth of JSON objects. The default in json-c is 32. Since we need to ++ * support at least 200 layers of snapshots (the limit is based on a ++ * conservative take on the 256 layer nesting limit for XML in libxml), for ++ * which we have internal checks, we also need to set the JSON limit to ++ * be able to parse qemu responses for such a deeply nested snapshot list. ++ * '300' is picked a sa conservative buffer on top of the 200 layers plus ++ * some of the extra wrappers that qemu adds*/ ++ tok = json_tokener_new_ex(300); + if (!tok) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("failed to create JSON tokener")); +-- +2.52.0 diff --git a/libvirt-virjsontest-Add-test-for-nesting-depth.patch b/libvirt-virjsontest-Add-test-for-nesting-depth.patch new file mode 100644 index 0000000..771947b --- /dev/null +++ b/libvirt-virjsontest-Add-test-for-nesting-depth.patch @@ -0,0 +1,45 @@ +From 953937e8beb9328de59b5f25eececb4901a416cc Mon Sep 17 00:00:00 2001 +Message-ID: <953937e8beb9328de59b5f25eececb4901a416cc.1769173967.git.jdenemar@redhat.com> +From: Peter Krempa +Date: Mon, 5 Jan 2026 15:00:18 +0100 +Subject: [PATCH] virjsontest: Add test for nesting depth +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Add an example of 250 layer deep nested JSON to make sure the parser +supports it. This is in order to maintain compatibility with external +snapshots in qemu, where such a deeply nested document is returned with +a 'query-block' QMP call. + +I've used a fake JSON as a real reply from qemu is around 1.4MiB for a +200 deep image chain. + +Signed-off-by: Peter Krempa +Reviewed-by: Ján Tomko +(cherry picked from commit 16804acf14616d7357ad6a336f2ffd6d255a8d63) +https://issues.redhat.com/browse/RHEL-135181 +--- + tests/virjsondata/parse-nesting-in.json | 1 + + tests/virjsondata/parse-nesting-out.json | 1 + + 2 files changed, 2 insertions(+) + create mode 100644 tests/virjsondata/parse-nesting-in.json + create mode 120000 tests/virjsondata/parse-nesting-out.json + +diff --git a/tests/virjsondata/parse-nesting-in.json b/tests/virjsondata/parse-nesting-in.json +new file mode 100644 +index 0000000000..8bbe1a3439 +--- /dev/null ++++ b/tests/virjsondata/parse-nesting-in.json +@@ -0,0 +1 @@ ++{"n249": {"n248": {"n247": {"n246": {"n245": {"n244": {"n243": {"n242": {"n241": {"n240": {"n239": {"n238": {"n237": {"n236": {"n235": {"n234": {"n233": {"n232": {"n231": {"n230": {"n229": {"n228": {"n227": {"n226": {"n225": {"n224": {"n223": {"n222": {"n221": {"n220": {"n219": {"n218": {"n217": {"n216": {"n215": {"n214": {"n213": {"n212": {"n211": {"n210": {"n209": {"n208": {"n207": {"n206": {"n205": {"n204": {"n203": {"n202": {"n201": {"n200": {"n199": {"n198": {"n197": {"n196": {"n195": {"n194": {"n193": {"n192": {"n191": {"n190": {"n189": {"n188": {"n187": {"n186": {"n185": {"n184": {"n183": {"n182": {"n181": {"n180": {"n179": {"n178": {"n177": {"n176": {"n175": {"n174": {"n173": {"n172": {"n171": {"n170": {"n169": {"n168": {"n167": {"n166": {"n165": {"n164": {"n163": {"n162": {"n161": {"n160": {"n159": {"n158": {"n157": {"n156": {"n155": {"n154": {"n153": {"n152": {"n151": {"n150": {"n149": {"n148": {"n147": {"n146": {"n145": {"n144": {"n143": {"n142": {"n141": {"n140": {"n139": {"n138": {"n137": {"n136": {"n135": {"n134": {"n133": {"n132": {"n131": {"n130": {"n129": {"n128": {"n127": {"n126": {"n125": {"n124": {"n123": {"n122": {"n121": {"n120": {"n119": {"n118": {"n117": {"n116": {"n115": {"n114": {"n113": {"n112": {"n111": {"n110": {"n109": {"n108": {"n107": {"n106": {"n105": {"n104": {"n103": {"n102": {"n101": {"n100": {"n99": {"n98": {"n97": {"n96": {"n95": {"n94": {"n93": {"n92": {"n91": {"n90": {"n89": {"n88": {"n87": {"n86": {"n85": {"n84": {"n83": {"n82": {"n81": {"n80": {"n79": {"n78": {"n77": {"n76": {"n75": {"n74": {"n73": {"n72": {"n71": {"n70": {"n69": {"n68": {"n67": {"n66": {"n65": {"n64": {"n63": {"n62": {"n61": {"n60": {"n59": {"n58": {"n57": {"n56": {"n55": {"n54": {"n53": {"n52": {"n51": {"n50": {"n49": {"n48": {"n47": {"n46": {"n45": {"n44": {"n43": {"n42": {"n41": {"n40": {"n39": {"n38": {"n37": {"n36": {"n35": {"n34": {"n33": {"n32": {"n31": {"n30": {"n29": {"n28": {"n27": {"n26": {"n25": {"n24": {"n23": {"n22": {"n21": {"n20": {"n19": {"n18": {"n17": {"n16": {"n15": {"n14": {"n13": {"n12": {"n11": {"n10": {"n9": {"n8": {"n7": {"n6": {"n5": {"n4": {"n3": {"n2": {"n1": {"n0": "end"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} +diff --git a/tests/virjsondata/parse-nesting-out.json b/tests/virjsondata/parse-nesting-out.json +new file mode 120000 +index 0000000000..d269172843 +--- /dev/null ++++ b/tests/virjsondata/parse-nesting-out.json +@@ -0,0 +1 @@ ++parse-nesting-in.json +\ No newline at end of file +-- +2.52.0 diff --git a/libvirt.spec b/libvirt.spec index 1111cb8..a5eee78 100644 --- a/libvirt.spec +++ b/libvirt.spec @@ -294,7 +294,7 @@ Summary: Library providing a simple virtualization API Name: libvirt Version: 11.10.0 -Release: 2%{?dist}%{?extra_release} +Release: 3%{?dist}%{?extra_release} License: GPL-2.0-or-later AND LGPL-2.1-only AND LGPL-2.1-or-later AND OFL-1.1 URL: https://libvirt.org/ @@ -309,6 +309,10 @@ Patch4: libvirt-tests-Test-virFileIsSharedFSOverride.patch Patch5: libvirt-util-Fix-race-condition-in-virFileIsSharedFSType.patch Patch6: libvirt-util-Fix-race-condition-in-virFileIsSharedFSOverride.patch Patch7: libvirt-util-Rework-virFileIsSharedFSOverride-using-virFileCheckParents.patch +Patch8: libvirt-util-json-Increase-JSON-nesting-limit-when-parsing-to-300.patch +Patch9: libvirt-virjsontest-Add-test-for-nesting-depth.patch +Patch10: libvirt-qemuSecurityMoveImageMetadata-Move-seclabels-only-to-virStorageSource-of-same-type.patch +Patch11: libvirt-esx-Allow-connecting-to-IPv6-server.patch Requires: libvirt-daemon = %{version}-%{release} @@ -2700,6 +2704,12 @@ exit 0 %endif %changelog +* Fri Jan 23 2026 Jiri Denemark - 11.10.0-3 +- util: json: Increase JSON nesting limit when parsing to 300 (RHEL-135181) +- virjsontest: Add test for nesting depth (RHEL-135181) +- qemuSecurityMoveImageMetadata: Move seclabels only to virStorageSource of same type (RHEL-114412) +- esx: Allow connecting to IPv6 server (RHEL-138300) + * Thu Dec 18 2025 Jiri Denemark - 11.10.0-2 - tests: add test for a single per-device smmuv3 (RHEL-74200) - qemu: Use pci_bus to identify multi-smmuv3 model (RHEL-74200)