Script 'mail_helper' called by obssrc
Hello community,

here is the log from the commit of package gimp for openSUSE:Factory checked in 
at 2026-07-14 13:46:25
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/gimp (Old)
 and      /work/SRC/openSUSE:Factory/.gimp.new.1991 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "gimp"

Tue Jul 14 13:46:25 2026 rev:168 rq:1365477 version:3.2.4

Changes:
--------
--- /work/SRC/openSUSE:Factory/gimp/gimp.changes        2026-04-21 
12:42:33.040768650 +0200
+++ /work/SRC/openSUSE:Factory/.gimp.new.1991/gimp.changes      2026-07-14 
13:46:28.375904939 +0200
@@ -1,0 +2,13 @@
+Mon Jul 13 06:20:59 UTC 2026 - Xiaoguang Wang <[email protected]>
+
+- Add gimp-CVE-2026-58379.patch:Fix PSP File Parsing Heap Buffer
+  Overflow (CVE-2026-58379, bsc#1270299)
+- Add gimp-CVE-2026-59089.patch:Fix Signed integer overflow
+  (CVE-2026-59089, bsc#1270440)
+
+-------------------------------------------------------------------
+Sat Jun 27 08:51:36 UTC 2026 - JS <[email protected]>
+
+- Lower gexiv2_min_version to 0.14.3, the one Leap 16.1 has atm
+
+-------------------------------------------------------------------

New:
----
  gimp-CVE-2026-58379.patch
  gimp-CVE-2026-59089.patch

----------(New B)----------
  New:
- Add gimp-CVE-2026-58379.patch:Fix PSP File Parsing Heap Buffer
  Overflow (CVE-2026-58379, bsc#1270299)
  New:  Overflow (CVE-2026-58379, bsc#1270299)
- Add gimp-CVE-2026-59089.patch:Fix Signed integer overflow
  (CVE-2026-59089, bsc#1270440)
----------(New E)----------

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ gimp.spec ++++++
--- /var/tmp/diff_new_pack.HHoJwP/_old  2026-07-14 13:46:29.795953477 +0200
+++ /var/tmp/diff_new_pack.HHoJwP/_new  2026-07-14 13:46:29.799953614 +0200
@@ -47,7 +47,7 @@
 %define exiv2_version           0.27.4
 %define gdk_pixbuf_version      2.30.8
 %define gegl_version            0.4.66
-%define gexiv2_min_version      0.14.5
+%define gexiv2_min_version      0.14.3
 %define gexiv2_max_version      0.15.0
 %define glib_version            2.70.0
 %define gtk3_version            3.24.50
@@ -101,6 +101,8 @@
 Patch1:         gimp-2.99.19-cm-system-monitor-profile-by-default.patch
 Patch2:         gimp-2.99.19-external-help-browser.patch
 Patch3:         gimp-2.99.19-no-phone-home-default.patch
+Patch4:         gimp-CVE-2026-58379.patch
+Patch5:         gimp-CVE-2026-59089.patch
 %if %{with debug_in_build_gimp}
 BuildRequires:  gdb
 %endif

++++++ gimp-CVE-2026-58379.patch ++++++
>From b630f167ba7b73b17e7dd6df1fee1623f8324575 Mon Sep 17 00:00:00 2001
From: Jacob Boerema <[email protected]>
Date: Wed, 22 Apr 2026 11:09:36 -0400
Subject: [PATCH] plug-ins: Fix #16205 PSP File Parsing Heap Buffer Overflow

A heap buffer overflow write vulnerability exists in GIMP's PSP file
format parser. When parsing a specially crafted .psp file, the
read_channel_data() function in file-psp.c writes beyond the bounds of
a heap-allocated buffer due to an inconsistency between the buffer
allocation size (line_width) and the read size (width). Opening a
crafted PSP file causes memory corruption during parsing.

The first part of the fix corrects the computation of the line_width,
which was incorrect for 1-bit per pixel. Since it needs to be on a
4 byte boundary, always add 3 instead of depending on bit depth.

Second, use the line_width instead of width to determine the number
of bytes to read and process because that is the correct number to use.
---
 plug-ins/common/file-psp.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/plug-ins/common/file-psp.c b/plug-ins/common/file-psp.c
index 6aae78c15f..1af2125c98 100644
--- a/plug-ins/common/file-psp.c
+++ b/plug-ins/common/file-psp.c
@@ -1558,7 +1558,7 @@ upscale_indexed_sub_8 (FILE    *f,
   guchar  *tmpbuf, *buf_start, *src;
 
   /* Scanlines for 1 and 4 bit only end on a 4-byte boundary. */
-  line_width = (((width * bpp + 7) / 8) + bpp_zero_based) / 4 * 4;
+  line_width = (((width * bpp + 7) / 8) + 3) / 4 * 4;
   buf_start = g_malloc0 (width * height);
   tmpbuf = buf_start;
 
@@ -1604,7 +1604,7 @@ read_channel_data (FILE        *f,
   if (ia->depth < 8)
     {
       /* Scanlines for 1 and 4 bit only end on a 4-byte boundary. */
-      line_width = (((width * ia->depth + 7) / 8) + ia->depth - 1) / 4 * 4;
+      line_width = ((width * ia->depth + 7) / 8 + 3) / 4 * 4;
     }
   else
     {
@@ -1627,7 +1627,7 @@ read_channel_data (FILE        *f,
                 {
                   guchar *p, *q;
 
-                  if (fread (buf, 1, width, f) != width)
+                  if (fread (buf, 1, line_width, f) != line_width)
                     {
                       g_set_error (error, G_FILE_ERROR, G_FILE_ERROR_FAILED,
                                    _("Error reading data. Most likely 
unexpected end of file."));
@@ -1637,7 +1637,7 @@ read_channel_data (FILE        *f,
                      scanlines are not stored on a 4-byte boundary. */
                   p = buf;
                   q = pixels[y] + offset;
-                  for (i = 0; i < width; i++)
+                  for (i = 0; i < line_width; i++)
                     {
                       *q = *p++;
                       q += bytespp;
@@ -2140,7 +2140,7 @@ read_layer_block (FILE      *f,
 
           if (ia->depth < 8)
             {
-              gint min_line_width = (((width * ia->depth + 7) / 8) + 
(ia->depth - 1)) / 4 * 4;
+              gint min_line_width = (((width * ia->depth + 7) / 8) + 3) / 4 * 
4;
 
               /* For small widths, when depth is 1, or 4, the number of bytes
                * used can be larger than the width * bytespp. Adjust for that. 
*/
-- 
2.54.0


++++++ gimp-CVE-2026-59089.patch ++++++
>From 53cdb27fa2b1676d11e9677c9975b5ad7b61b2ee Mon Sep 17 00:00:00 2001
From: Alx Sa <[email protected]>
Date: Mon, 15 Jun 2026 04:37:14 +0000
Subject: [PATCH] plug-ins: Mitigate issue #16493

Resolves #16493
It is possible for an invalid TIM file to set both
the number of colors and number of CLUTs to the
maximum gushort value. In that case, when multiplied
they may overflow the size of a guint. To prevent this,
the "clut_size" variable is changed to a gsize datatype.
This allows the code to flow through to other checks
without risking an overflow.
---
 plug-ins/common/file-tim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plug-ins/common/file-tim.c b/plug-ins/common/file-tim.c
index baa8ed9f08..6a0dafcb84 100644
--- a/plug-ins/common/file-tim.c
+++ b/plug-ins/common/file-tim.c
@@ -483,7 +483,7 @@ load_image (GFile        *file,
      if (num_colors > 0)
       {
         gboolean  promote_to_rgb = FALSE;
-        guint     clut_size      = num_colors * num_cluts;
+        gsize     clut_size      = num_colors * num_cluts;
         gushort  *clut_data;
         guchar   *color_map;
         guint32   image_offset;
-- 
2.54.0

Reply via email to