Bug#1122347: glib#3834, CVE-2025-14087: signed integer overflow parsing GVariant text format

[Simon McVittie]

Source: glib2.0
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/glib/-/issues/3834
X-Debbugs-Cc: Debian Security Team <team at security.debian.org>, debian-lts at lists.debian.org
Control: close -1 2.86.3-1

There are some signed integer overflows possible when GLib parses 
strings in the GVariant text format that encode a very large string, 
bytestring or sequence (array, dict, tuple). By "very large" I mean 
gigabytes. This could in theory be a security vulnerability if some 
component is (IMO unwisely!) parsing attacker-supplied GVariant text 
strings without imposing a reasonable size limit. This issue is also 
known as glib#3834 or YWH-PGM9867-145.

The GVariant text format is an inefficient representation used for 
debugging and human-editable configuration: if you think of it as a 
strongly-typed alternative to JSON, that's a good mental model.
Like JSON, it doesn't really make sense for anything larger than maybe a 
megabyte, especially when there is an equally expressive binary format 
that encodes the same information in a much more efficient way. As far 
as I can see, the GVariant *binary* format (the one that could 
potentially make sense for gigabytes of data) is unaffected by this 
vulnerability.

Security team: do I assume correctly that this is trixie-pu material, 
rather than something for which you would want to issue a DSA? It 
doesn't seem urgent to me.

For (old)stable and LTS I think it would make sense to handle backports 
of all of the changes made in GLib 2.86.3 (excluding the 
Windows-specific glib#3819 which doesn't affect Debian architectures) as 
a single batch. This would also include CVE-2025-13601 (glib#3827 
upstream, #1121488).

    smcv