Bug#1107797: glib2.0: CVE-2025-6052

[Simon McVittie]

On Sat, 14 Jun 2025 at 22:51:55 +0200, Salvatore Bonaccorso wrote:
>[1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4655

I don't think this is plausibly attacker-triggerable: it would require 
an attacker to be able to cause succesful (!) allocation of a GString 
object, and some data to append to it, that add up to more than the 
total address space (4 GiB on 32-bit, or 2**64 bytes on 64-bit).

On 64-bit, there's no reasonable scenario where we would run out of 
address space before running out of actual memory.

On 32-bit, the only way I can think of for the length calculation to 
overflow would be if there is an attacker-triggerable way to append an 
arbitrarily large substring of the target string (or the entire target 
string) to itself; otherwise the current size of the GString, plus the 
characters that are to be appended, must already both fit in virtual 
memory and therefore can't possibly add up to more than the limit of 
size_t (even if we ignore the parts of virtual memory that are used for 
other things: the kernel, the program, and GLib itself). I'm not at all 
convinced that a program containing that pattern exists.

So I don't think this is urgent to fix.

     smcv