From a05a48b756de63e3234ea6b3b938b8f5f862484a Mon Sep 17 00:00:00 2001
From: Cosmin Truta <ctruta@gmail.com>
Date: Mon, 1 Dec 2025 22:31:54 +0200
Subject: [PATCH] Finalize the fix for out-of-bounds read in
 `png_image_read_composite`

Following up on commit 788a624d7387a758ffd5c7ab010f1870dea753a1.

The previous commit added a defensive bounds check to address the
security issue (out-of-bounds read), but noted that the correctness
issue remained: when the clamp triggered, the affected pixels were
clamped to white instead of the correct composited color.

This commit addresses the correctness issue by fixing the flag
synchronization error identified in the previous commit's TODO:

1. In `png_init_read_transformations`:
   Clear PNG_FLAG_OPTIMIZE_ALPHA when clearing PNG_COMPOSE for palette
   images. This correctly signals that the data is sRGB, not linear
   premultiplied.

2. In `png_image_read_composite`:
   Check PNG_FLAG_OPTIMIZE_ALPHA and use the appropriate composition
   formula. When set, use the existing linear composition. When cleared
   (palette composition already done), use sRGB composition to match
   what was done to the palette.

Retain the previous clamp to the valid range as belt-and-suspenders
protection against any other unforeseen cases.

CVE: CVE-2025-66293
Upstream-Status: Backport [https://github.com/pnggroup/libpng/commit/a05a48b756de63e3234ea6b3b938b8f5f862484a]
Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 pngread.c  | 56 ++++++++++++++++++++++++++++++++++++------------------
 pngrtran.c |  1 +
 2 files changed, 39 insertions(+), 18 deletions(-)

diff --git a/pngread.c b/pngread.c
index ab62edd9d..f8ca2b7e3 100644
--- a/pngread.c
+++ b/pngread.c
@@ -3338,6 +3338,7 @@ png_image_read_composite(png_voidp argument)
       ptrdiff_t    step_row = display->row_bytes;
       unsigned int channels =
           (image->format & PNG_FORMAT_FLAG_COLOR) != 0 ? 3 : 1;
+      int optimize_alpha = (png_ptr->flags & PNG_FLAG_OPTIMIZE_ALPHA) != 0;
       int pass;
 
       for (pass = 0; pass < passes; ++pass)
@@ -3394,25 +3395,44 @@ png_image_read_composite(png_voidp argument)
 
                      if (alpha < 255) /* else just use component */
                      {
-                        /* This is PNG_OPTIMIZED_ALPHA, the component value
-                         * is a linear 8-bit value.  Combine this with the
-                         * current outrow[c] value which is sRGB encoded.
-                         * Arithmetic here is 16-bits to preserve the output
-                         * values correctly.
-                         */
-                        component *= 257*255; /* =65535 */
-                        component += (255-alpha)*png_sRGB_table[outrow[c]];
+                        if (optimize_alpha != 0)
+                        {
+                           /* This is PNG_OPTIMIZED_ALPHA, the component value
+                            * is a linear 8-bit value.  Combine this with the
+                            * current outrow[c] value which is sRGB encoded.
+                            * Arithmetic here is 16-bits to preserve the output
+                            * values correctly.
+                            */
+                           component *= 257*255; /* =65535 */
+                           component += (255-alpha)*png_sRGB_table[outrow[c]];
 
-                        /* So 'component' is scaled by 255*65535 and is
-                         * therefore appropriate for the sRGB-to-linear
-                         * conversion table.  Clamp to the valid range
-                         * as a defensive measure against an internal
-                         * libpng bug where the data is sRGB rather than
-                         * linear premultiplied.
-                         */
-                        if (component > 255*65535)
-                           component = 255*65535;
-                        component = PNG_sRGB_FROM_LINEAR(component);
+                           /* Clamp to the valid range to defend against
+                            * unforeseen cases where the data might be sRGB
+                            * instead of linear premultiplied.
+                            * (Belt-and-suspenders for GitHub Issue #764.)
+                            */
+                           if (component > 255*65535)
+                              component = 255*65535;
+
+                           /* So 'component' is scaled by 255*65535 and is
+                            * therefore appropriate for the sRGB-to-linear
+                            * conversion table.
+                            */
+                           component = PNG_sRGB_FROM_LINEAR(component);
+                        }
+                        else
+                        {
+                           /* Compositing was already done on the palette
+                            * entries.  The data is sRGB premultiplied on black.
+                            * Composite with the background in sRGB space.
+                            * This is not gamma-correct, but matches what was
+                            * done to the palette.
+                            */
+                           png_uint_32 background = outrow[c];
+                           component += ((255-alpha) * background + 127) / 255;
+                           if (component > 255)
+                              component = 255;
+                        }
                      }
 
                      outrow[c] = (png_byte)component;
diff --git a/pngrtran.c b/pngrtran.c
index 2f5202255..507d11381 100644
--- a/pngrtran.c
+++ b/pngrtran.c
@@ -1760,6 +1760,7 @@ png_init_read_transformations(png_structrp png_ptr)
              * transformations elsewhere.
              */
             png_ptr->transformations &= ~(PNG_COMPOSE | PNG_GAMMA);
+            png_ptr->flags &= ~PNG_FLAG_OPTIMIZE_ALPHA;
          } /* color_type == PNG_COLOR_TYPE_PALETTE */
 
          /* if (png_ptr->background_gamma_type!=PNG_BACKGROUND_GAMMA_UNKNOWN) */