Bug#1110640: glib2.0: CVE-2025-7039: buffer underrun in get_tmp_file()

[Simon McVittie]

Source: glib2.0
Severity: important
Tags: security pending fixed-upstream
X-Debbugs-Cc: Debian Security Team <team at security.debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/glib/-/issues/3716
Control: fixed -1 2.84.4-1

glib2.0's implementation of tempnam()-like functionality, used in 
g_mkstemp(), g_mkdtemp() and similar functions, has a buffer underrun 
caused by a signed integer overflow if a program creates 2**31 or more 
temporary files. If this happens, instead of the XXXXXX in the template 
filename being replaced by alphanumeric characters from a read-only 
array, they will be replaced by (some of) whatever 36 bytes happen to be 
before that array in the library's .rodata segment.

The upstream bug reporter claims that this is a security vulnerability, 
because the 36 bytes before the array could conceivably contain a slash, 
and an attacker could make use of that to create a directory they 
control and exploit from there. This seems like a tenuous claim to me, 
and upstream is not treating this as particularly serious. I haven't 
attempted to check whether any of our specific binary builds of GLib 
happen to contain problematic data just before the alphabet.

A mitigation is that if a single run of a program creates fewer than 2 
billion temporary files, the signed integer overflow won't occur, 
resulting in the array underflow also not occurring.

Do I assume correctly that this is going to be no-dsa?

I uploaded a fixed version to unstable, which I intend to rebuild as 
2.84.4-1~deb13u1 for 13.1. The version in experimental is unfixed, but 
2.85.3-1 will fix it.

    smcv