GVariant type depth not checked on typedecls in text format variants

oss-fuzz has found a latent issue with GVariant depth restrictions which needs fixing, and should probably be treated as a security issue.

If I have a text-form GVariant [1,2,3,4] and it’s parsed using g_variant_parse() without specifying a type, then adding a deeply-nested typedecl inside it ([1,2,3,4,@mmmm…mmu 0]) will multiply the number of objects created by the nesting depth. This means the number of objects created is not linear in the length of the text-form GVariant, which can be used to perform denial of service attacks.

This is exploitable only in software which parses untrusted text-form GVariants without specifying a type. This is unlikely, and is already a very risky thing for that software to do. For that reason, I don’t think we need to go through coordinated release of fixes or request a CVE number.

I have attached a patch which fixes the issue and includes a text case. It basically causes g_variant_parse() to return G_VARIANT_PARSE_ERROR_RECURSION if faced with a typedecl in a text-form GVariant where the depth of the type in the typedecl would cause the whole variant to become too deeply nested at any point.

0001-gvariant-parser-Reject-deeply-nested-typedecls-in-te.patch

We’ll have to do patch review manually in this issue, in order to keep the fix confidential until it’s ready to release, since GitLab doesn’t yet support confidential MRs (afaik).

I’ve set the due date to 2 days before the oss-fuzz issue becomes public. Sorry for the short notice; I was only reminded of this issue because of an oss-fuzz deadline reminder. This kind of rush could be avoided if it wasn’t just me looking at oss-fuzz issues. We can request up to 2 weeks’ extension on the oss-fuzz deadline if needed, as a fix is in progress.