Bug#1109262: CVE-2025-7345: gdk-pixbuf: heap buffer overflow in JPEGs with chunked ICC data

[Simon McVittie]

On Mon, 14 Jul 2025 at 12:15:36 +0100, Simon McVittie wrote:
>I happened to notice that a buffer overflow was reported and fixed
>upstream, involving parsing a JPEG file with multiple chunks of embedded
>ICC colour-correction data.

Cyril reminded me that the fixed version is still only in unstable, and 
has not migrated to trixie. I've been reluctant to ask for an unblock or 
backport the change into bookworm, because I was concerned about 
possible regressions.

For context, gdk-pixbuf has three main use-cases:

- GTK apps use it to load trusted resources like icons. Security doesn't
   really matter here: an attacker should not have the opportunity to
   inject a crafted, malicious icon into the app.

- Some older image viewers such as gthumb, eog and eom use it as a
   general-purpose image loader. IMO this is the most concerning exposure
   to untrusted images. It is increasingly clear that early 00s C code
   written in the typical ad-hoc style is not a great fit for this use,
   and upstream no longer recommend gdk-pixbuf for this purpose: instead
   they recommend using something sandboxed and/or written in a memory-safe
   language, like glycin (which uses sandboxed Rust code). The version of
   GNOME in trixie defaults to installing loupe (a glycin-based image
   viewer) in preference to eog (an older gdk-pixbuf-based viewer)
   but other desktops like MATE and bookworm's GNOME still install
   gdk-pixbuf-based image viewers, and existing GNOME installations
   upgraded to trixie will still have eog.

- libgnome-desktop uses gdk-pixbuf for thumbnailing. This is exposed to
   untrusted images, and in principle more dangerous than the image viewer
   use-case because thumbnailing is usually automatic; but since 2017 it's
   rather strictly sandboxed with bubblewrap, mitigating vulnerabilities.

The buffer overflow CVE-2025-7345 was discovered via fuzzing and we do 
not know what its impact is: could be essentially harmless in practice, 
could be denial of service, could conceivably be arbitrary code 
execution when not sandboxed, I have no idea.

gdk-pixbuf's image loading code is likely to become a wrapper around 
glycin (at least on release architectures) during the GNOME 49 cycle, 
avoiding this whole class of potential vulnerabilities, but that work is 
currently ongoing upstream and was not ready in time for trixie, so we 
can't wait for it.

>(It has not been fixed in a release, only in
>the upstream development branch.)

This is still the case, so presumably upstream is not treating this as a 
high-priority fix at the moment.

Looking at our friends, colleagues and/or competitors in other distros, 
Fedora has left the CVE unfixed for the moment, but Ubuntu has applied a 
patch in their stable/LTS releases (and might be able to share whether 
they have experienced regressions).

>Since uploading the fixed version to unstable, we've had a report of a
>regression, https://bugs.debian.org/1109199, which I forwarded upstream
>as https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/262. I cannot
>reproduce the regression, and the regression reporter has not provided
>enough details to make it actionable

The regression reporter now says they cannot reproduce the regression 
either. I don't know what was happening there.

>I think we should probably leave this unfixed in stable and LTS for now,
>until we have a better idea of whether the regression is a real thing.

What does the security team want to do about this? Fix in trixie now, or 
fix via trixie-security before or after 13.0, or wait for 13.1?

>I am by no means an expert on either the gdk-pixbuf codebase, the finer
>points of JPEG parsing, or reproducing fuzzer-generated crashes in a
>more reasonable environment, so I would very much appreciate it if
>someone who is better at those topics (and ideally someone who can spend
>their paid time on it!) can take it from here.

This is still the case and I would appreciate help.

     smcv