[PATCH] util: json: Increase JSON nesting limit when parsing to 300
From: Peter Krempa <pkrempa@redhat.com> 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 <pkrempa@redhat.com> --- 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=%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
On a Thursday in 2025, Peter Krempa via Devel wrote:
From: Peter Krempa <pkrempa@redhat.com>
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.
Do you, by any chance, have a response this long that could be added to our test suite?
'json_tokener_new_ex' is supported since json-c 0.11 and we require at least 0.14.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> ---
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(-)
Reviewed-by: Ján Tomko <jtomko@redhat.com> Jano
On Fri, Dec 12, 2025 at 11:50:39 +0100, Ján Tomko wrote:
On a Thursday in 2025, Peter Krempa via Devel wrote:
From: Peter Krempa <pkrempa@redhat.com>
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.
Do you, by any chance, have a response this long that could be added to our test suite?
Sure; obtaining it is not a problem. I'll look where we could reasonably put such a test so that it makes sense. If you don't mind I'll submit it separately
participants (2)
-
Ján Tomko -
Peter Krempa