A flaw exists in gdk‑pixbuf within the gdk_pixbuf__jpeg_image_load_increment function

The bug lives in gdk_pixbuf__jpeg_image_load_increment() inside io-jpeg.c. When gdk-pixbuf encounters a JPEG carrying multiple embedded ICC color-profile chunks, it hands them off to glib's g_base64_encode_step() for reassembly and mis-sizes the destination buffer — resulting in a heap out-of-bounds write during Base64 encoding of the concatenated ICC blob. Any GTK/GNOME-based consumer of untrusted images (Nautilus thumbnailers, Eye of GNOME, Evolution, Firefox on some builds, tracker-miners, Thunderbird preview) is in the reachable set. Affected: gdk-pixbuf up through 2.42.12 pre-patch; fixed in upstream commit 4af78023 and shipped as Debian 2.42.12+dfsg-4, Ubuntu USN-7662-1, RHEL/SUSE backports, Fedora updates.

The vendor HIGH (7.5, C:N/I:N/A:H) is honest but slightly misleading in framing. It's *availability-only* — the reference scoring treats the OOB access as a reliable crash, not RCE. That maps to real practitioner impact of MEDIUM: this is a thumbnailer-crash / DoS class bug across the Linux desktop, not a wormable RCE. If you're running a headless Linux fleet with no GUI stack, the exposure is closer to LOW; if you're a workstation shop or your MTAs/webmail render inline JPEGs via gdk-pixbuf, it stays MEDIUM.

Why this verdict

• Availability-only impact by design of the vector — NVD C:N/I:N/A:H. The observed primitive is an out-of-bounds *write* using Base64-alphabet bytes only, which is a poor foundation for a control-flow hijack without a separate info-leak.
• Friction: modern Linux hardening blunts exploitation — full RELRO, PIE/ASLR, _FORTIFY_SOURCE, glibc allocator sanity checks, and increasingly sandboxed thumbnailers (Flatpak, bwrap) all sit between the write and any useful outcome.
• Friction: EPSS 0.01, no KEV, no ITW — attacker interest is essentially zero six-plus months post-disclosure.
• Role multiplier: workstation desktops — chain succeeds trivially as a crash of gnome-thumbnail-factory / image viewer / mail client preview. Blast radius = one user session, self-heals on respawn. This is the dominant real-world role.
• Role multiplier: headless servers — chain generally does NOT succeed; gdk-pixbuf is not loaded by any server-critical process. Blast radius = none if the package isn't pulled in transitively.
• Role multiplier: mail/collab gateways rendering inline images — chain succeeds as DoS of the renderer. Not a high-value-role component under noisgate's catalog (not IdP, hypervisor, PAM, CA, backup, kernel agent, or edge appliance), so no CRITICAL floor is triggered.
• Widespread install base keeps it MEDIUM, not LOW — practically every GNOME/GTK workstation is affected; nuisance-scale outages are plausible at fleet scale.

Why not higher?

No public path from the Base64-alphabet OOB write to reliable code execution, no in-the-wild exploitation, EPSS floor-level, and the affected component is not a canonical high-value role (identity, hypervisor, PAM, backup, CA, kernel-mode agent, or edge appliance). The vendor HIGH 7.5 is driven by A:H alone, which does not map to an operational HIGH bucket.

Why not lower?

The install base is essentially every Linux desktop and any distro that pulls in GTK/GNOME transitively; the primitive is unauthenticated and requires no user interaction on hosts with thumbnailers or image-rendering mail clients. Dismissing it as LOW would ignore both the reachability and the residual possibility of code execution by a motivated attacker.

1. Apply distro package updates for gdk-pixbuf and glib2 fleet-wide — This is the primary fix — pull Ubuntu USN-7662-1, RHEL / SUSE / Debian security-updates, or the Fedora update. Deploy via your standard patch cycle within the noisgate remediation SLA of 365 days for MEDIUM; no mitigation SLA applies.
2. Confirm thumbnailer sandboxing — Verify gnome-thumbnail-factory and equivalents run under bwrap / Flatpak sandbox on your desktop image. If you deploy vanilla GNOME 44+ this is default; check /usr/share/thumbnailers/*.thumbnailer for X-GNOME-Sandbox=true.
3. Strip / audit inline image rendering in mail clients — Evolution, Thunderbird, and Geary render inline images via gdk-pixbuf on some builds. Set 'do not load remote images' policies and consider disabling attachment preview until patched.
4. Enable systemd-coredump alerting for gdk-pixbuf-linked processes — Forward systemd-coredump events to your SIEM and alert on repeated crashes in evince, gnome-thumbnail-factory, nautilus, firefox (Linux). Repeated crashes on one host are the signal that someone is iterating exploitation.
5. SBOM sweep for embedded gdk-pixbuf/glib in container images — Third-party containers that ship a GUI stack (Selenium Grid nodes, GUI-based CI runners, RDP/VNC servers) often carry old gdk-pixbuf. Trivy / Grype / Syft your registry.

Run this on each Linux target host as root or via your config-management push (Ansible, Salt, Puppet). Example: sudo bash check-cve-2025-7345.sh. Detects gdk-pixbuf package version across Debian/Ubuntu, RHEL/Fedora, and SUSE and compares against known fixed thresholds. Exits 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN.

#!/usr/bin/env bash
# noisgate: CVE-2025-7345 gdk-pixbuf heap OOB via chunked ICC JPEG
set -u

VULN=1
PATCHED=0
UNKNOWN=2

verdict() {
  case "$1" in
    $VULN)    echo "VULNERABLE: $2"; exit $VULN ;;
    $PATCHED) echo "PATCHED: $2";    exit $PATCHED ;;
    *)        echo "UNKNOWN: $2";    exit $UNKNOWN ;;
  esac
}

# Debian/Ubuntu
if command -v dpkg-query >/dev/null 2>&1; then
  V=$(dpkg-query -W -f='${Version}' libgdk-pixbuf-2.0-0 2>/dev/null || \
      dpkg-query -W -f='${Version}' libgdk-pixbuf2.0-0 2>/dev/null || true)
  if [ -n "$V" ]; then
    # Debian fix: 2.42.12+dfsg-4 ; Ubuntu USN-7662-1 backports across releases
    if dpkg --compare-versions "$V" ge "2.42.12+dfsg-4"; then
      verdict $PATCHED "gdk-pixbuf $V (>= 2.42.12+dfsg-4)"
    else
      verdict $VULN "gdk-pixbuf $V (< 2.42.12+dfsg-4)"
    fi
  fi
fi

# RHEL/Fedora
if command -v rpm >/dev/null 2>&1; then
  V=$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' gdk-pixbuf2 2>/dev/null | grep -v 'not installed' | head -1)
  if [ -n "$V" ]; then
    # Consult vendor errata; treat any release explicitly noting CVE-2025-7345 as patched
    if rpm -q --changelog gdk-pixbuf2 2>/dev/null | grep -q 'CVE-2025-7345'; then
      verdict $PATCHED "gdk-pixbuf2 $V (changelog cites CVE-2025-7345)"
    else
      verdict $VULN "gdk-pixbuf2 $V (no CVE-2025-7345 fix in changelog)"
    fi
  fi
fi

verdict $UNKNOWN "gdk-pixbuf package not detected on this host"

Sources

1. Red Hat Bugzilla 2377063
2. GitHub Advisory GHSA-xrq2-m5w8-p5wg
3. Ubuntu Security CVE-2025-7345
4. Rapid7 USN-7662-1
5. Snyk SNYK-DEBIAN12-GDKPIXBUF-10663977
6. SUSE advisory 2025:03010-1
7. Debian bug 1109262
8. Upstream fix commit 4af78023