Source: glib2.0
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/glib/-/issues/3834
X-Debbugs-Cc: Debian Security Team <[email protected]>,
[email protected]
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
