From nobody Fri Dec 12 12:55:33 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1765446538; cv=none; d=zohomail.com; s=zohoarc; b=Sz4xWfsnhlkrsCRcopgS7D+bGCOSW98R1RW0+zPB2eWQvrbd6gNRzqLWAqyXqcg6vsVWR10ET8ssxrNHnHG7BAnoEMt7f1hnJL8R++WXDk/B1ry1PqDLUBaGNsaiSYiHNYMT5XDP/SozuIF4jNUKCDR/RRIuOGCd49w9RjQGsUo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1765446538; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:Subject:Subject:To:To:Message-Id:Cc; bh=5tJv/UypZ04MIyz6VkmQbePlIS8M7rdCAst34o1dgh0=; b=RZlACDq6aFyr/NGhnjrvRh4CvTPzbDJbOs07DwWVdfGn0hyzWvKtcaeibwG/6kHClMHXgWmIiM1gdH0hPBptWaDc0+yfnb1eB1/i98iZz05dgLOscOlTn4ntGDKgxTRHyqVAHAr4HBRNCz+k2XAwEKv+Lz9vHdEM5WuyySmV3J4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1765446538739325.2620418637101; Thu, 11 Dec 2025 01:48:58 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 993) id 7E53441A62; Thu, 11 Dec 2025 04:48:56 -0500 (EST) Received: from [172.19.199.80] (lists.libvirt.org [8.43.85.245]) by lists.libvirt.org (Postfix) with ESMTP id DE81541B3B; Thu, 11 Dec 2025 04:48:13 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 993) id 73DCE418AF; Thu, 11 Dec 2025 04:48:06 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 1AAFB41A15 for ; Thu, 11 Dec 2025 04:48:03 -0500 (EST) Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-596-VzLEar0YO5-rzdvAMsJGyw-1; Thu, 11 Dec 2025 04:48:02 -0500 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1CFAC1800358 for ; Thu, 11 Dec 2025 09:48:01 +0000 (UTC) Received: from speedmetal.openshiftapps.com (unknown [10.44.22.4]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 50E971800451 for ; Thu, 11 Dec 2025 09:48:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_PASS autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1765446483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=5tJv/UypZ04MIyz6VkmQbePlIS8M7rdCAst34o1dgh0=; b=COhduVxDJdCJzQxGu4vsPUJAE90c1B4l00l0NGhP0vvFbnKG7q7ryQFt6SRlrSQosbSRXn 7OifbVzcsRn/a/CsZ5us1NdVa6H7Osqi2mMfvhEpIzxa2jf9ovj4oRSScOZExa9AcPVWOE macbxl/pMcnk/rPpX7XLjpGNTmXs+JM= X-MC-Unique: VzLEar0YO5-rzdvAMsJGyw-1 X-Mimecast-MFC-AGG-ID: VzLEar0YO5-rzdvAMsJGyw_1765446481 To: devel@lists.libvirt.org Subject: [PATCH] util: json: Increase JSON nesting limit when parsing to 300 Date: Thu, 11 Dec 2025 10:47:58 +0100 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: qWLKsEDjUqCVBhP6BGuJyDbx4t9_RuWjpWBTK4hQxwE_1765446481 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: VMDMHV3GWTTTF54WD5PIT2NJIU5NAZMM X-Message-ID-Hash: VMDMHV3GWTTTF54WD5PIT2NJIU5NAZMM X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Peter Krempa via Devel Reply-To: Peter Krempa X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1765446541680158500 Content-Type: text/plain; charset="utf-8" From: Peter Krempa 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=C3=A1n Tomko --- I've also figured out that we don't actually care about the backing image information so I've proposed a 'flat' mode for 'query-block' in qemu similarly to what we do for 'query-named-block-nodes': https://mail.gnu.org/archive/html/qemu-block/2025-12/msg00104.html 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=3D%s", jsonstring); - tok =3D json_tokener_new(); + /* When creating the tokener we need to specify the limit of the nesti= ng + * 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 l= ist. + * '300' is picked a sa conservative buffer on top of the 200 layers p= lus + * some of the extra wrappers that qemu adds*/ + tok =3D json_tokener_new_ex(300); if (!tok) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("failed to create JSON tokener")); --=20 2.52.0