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

[Salvatore Bonaccorso]

Hi Simon,

On Sat, Jul 26, 2025 at 03:16:59PM +0100, Simon McVittie wrote:
> 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?

At this point in time, if you do not feel confortable to have it
unblocked for trixie, then let's rather wait for the first point
release. For instance for bookworm we did mark it as no-dsa/postponed
so that the fix is exposed first in any case in the upper suites (and
if regressions are uncovered). The one reported seems to have matured
to a false-positive.

But if you are confident at this point with the 14 days of exposure in
unstable with no additional regression reports (and maybe compare with
Ubuntu's update), an unblock now for trixie would at least ensure we
start with a "clean" page for gdk-pixbuf for trixie's release.

Regards,
Salvatore