Debian Patches

Status for gimp/3.2.0~RC2-3.3

Patch Description Author Forwarded Bugs Origin Last update
devel-docs-Use-API-version-not-app-version-for-install-lo.patch devel-docs: Use API version not app version for install location
In other words, 3.0 instead of 3.2		 Jeremy Bícha <jbicha@debian.org> yes 2025-12-05
plug-ins-fix-15284-ZDI-CAN-28232-vulnerability-in-fi.patch plug-ins: fix #15284 ZDI-CAN-28232 vulnerability in file-psp
We were not checking whether channel types were valid for grayscale
images. Using a blue color channel caused an invalid computation of
the offset which could cause us to access an invalid memory location.

Now we separate RGB from non-RGB images when checking which channels
are valid, and if not return with an error.		 Jacob Boerema <jgboerema@gmail.com> yes debian upstream https://gitlab.gnome.org/GNOME/gimp/-/commit/03575ac8cbb0ef3103b0a15d6598475088dcc15e 2025-12-20
plug-ins-fix-15812-PSD-loader-heap-buffer-overflow.patch plug-ins: fix #15812 PSD loader: heap-buffer-overflow ...
in fread_pascal_string

In plug-ins/file-psd/psd-util.c, the function fread_pascal_string()
allocates a buffer with g_malloc(len) and reads len bytes from the file
into it. The buffer is not null-terminated, but is assumed to be in
later code.
This causes it to read past the end of its allocated region with a
specially crafted PSD, causing a heap-buffer-overflow.

Fix this by alloocating one more byte than its length and set that
to '\0'.

(cherry picked from commit 8cf2772f5631719ae0e4e701bd7ef793b1f59cfa)		 Jacob Boerema <jgboerema@gmail.com> yes debian upstream https://gitlab.gnome.org/GNOME/gimp/-/commit/51a2d65a2df403f6da582173e0ddd7904356f5ae 2026-02-06
plug-ins-Fix-15732-PSP-File-Parsing-Integer-Overflow.patch plug-ins: Fix #15732 PSP File Parsing Integer Overflow...
Leading to Heap Corruption

An integer overflow vulnerability has been identified in the PSP
(Paint Shop Pro) file parser of GIMP. The issue occurs in the
read_creator_block() function, where the Creator metadata block is
processed. Specifically, a 32-bit length value read from the file is
used directly for memory allocation without proper validation.
Trigger -> when length is set to 0xFFFFFFFF

To fix this, we check that using that length doesn't exceed the end
of the creator block. If it does, we return with an error message.		 Jacob Boerema <jgboerema@gmail.com> yes debian upstream https://gitlab.gnome.org/GNOME/gimp/-/commit/0e63f096fa5f7dc3fae0a8e865fd5a05ebe45da8 2026-01-23
plug-ins-Add-overflow-checks-for-ICO-loading.patch plug-ins: Add overflow checks for ICO loading
As pointed out by Dhiraj, it is possible to set width and
height values in the ICO header that will overflow a 32 bit
integer when loaded in. This patch adds checks using
g_size_check_mul () and g_try_new () to catch these
overflows and prevent them from crashing the plug-in.		 Alx Sa <cmyk.student@gmail.com> yes debian upstream https://gitlab.gnome.org/GNOME/gimp/-/commit/058ada8f3ffc0a42b7dd1561a8817c8cc83b7d2a 2026-01-12
plug-ins-fix-crash-due-to-uninitialized-ptr_array.patch plug-ins: fix crash due to uninitialized ptr_array...
when loading a specially crafted PSD.
After fixing the issue in the previous commit, using the poc from that
issue, a new issue surfaced where the ptr_array used for
img_a->alpha_name did not contain any names. Trying to access the
first index then caused a crash, because apparently that is only
valid if at least one item has been added.

Let's fix this by only creating the ptr_array when we know for sure
that we are going to add an item.		 Jacob Boerema <jgboerema@gmail.com> no https://gitlab.gnome.org/GNOME/gimp/-/commit/02886e626df5e4c5f73f838a64fd3f21809dda09 2026-02-06

All known versions for source package 'gimp'

Links