Bug#1122346: glib#3845: (no CVE): Integer overflow in file attribute escaping

[Salvatore Bonaccorso]

Hi Simon,

On Wed, Dec 10, 2025 at 11:53:30AM +0000, Simon McVittie wrote:
> Source: glib2.0
> Severity: important
> Tags: security fixed-upstream
> Forwarded: https://gitlab.gnome.org/GNOME/glib/-/issues/3845
> X-Debbugs-Cc: Debian Security Team <team at security.debian.org>, debian-lts at lists.debian.org
> Control: close -1 2.86.3-1
> 
> From the upstream issue report:
> >The escape_byte_string() function in GLib's gio/gfileattribute.c uses
> >a signed integer num_invalid to count characters requiring escaping
> >before allocating an output buffer. When a file attribute (such as
> >G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME) contains a large number of
> >invalid characters, the multiplication num_invalid * 3 can overflow
> >the signed integer. This causes g_malloc(len + num_invalid*3 + 1)
> >to allocate a buffer smaller than required. The subsequent escaping
> >loop writes 4 bytes (\xCC format) per invalid character into this
> >buffer, causing a heap buffer overflow. The issue is triggered when
> >g_file_info_get_attribute_as_string() is called to retrieve byte string
> >attributes.
> 
> In principle an attacker could intentionally cause denial of service, or 
> even heap corruption, using a file attribute of size >= 1 GiB, making 
> this maybe a security issue.
> 
> Upstream treated this as a (minor) security issue, but there is no CVE 
> ID that I am aware of. I would suggest fixing it in (old)stable and LTS 
> as part of the same batch as the two CVEs fixed in 2.86.3 upstream, 
> CVE-2025-14087 (glib#3834 upstream, Debian bug report pending) and 
> CVE-2025-13601 (glib#3827 upstream, #1121488 in Debian).
> 
> Security team: do I assume correctly that this is all trixie-pu 
> material, rather than something for which you would want to issue a DSA? 
> None of the fixes in GLib 2.86.3 seem urgent to me.

Yes seems sensible to handle this via the upcoming point releases and
no DSA is needed. I have marked as well the second CVE as no-dsa
accordingly.

Regards,
Salvatore