[libpng14] Fixed the recently reported 1's complement security issue by

replacing the value that is illegal in the PNG spec, in both signed and
unsigned values, with 0. Illegal unsigned values (anything greater than or equal
to  0x80000000) can still pass through, but since these are not illegal
in ANSI-C (unlike 0x80000000 in the signed case) the checking that
occurs later can catch them (John Bowler).

Safely convert num_bytes to a png_byte in png_set_sig_bytes() (Robert
Seacord).

1 files changed, 7 insertions, 2 deletions

diff --git a/pngrutil.c b/pngrutil.c
index c5fc80468..25b8b88a3 100644
--- a/pngrutil.c
+++ b/pngrutil.c
@@ -41,8 +41,13 @@ png_uint_32 (PNGAPI
 png_get_uint_32)(png_bytep buf)
 {
    png_uint_32 uval = png_get_uint_32(buf);
-   if ((uval & 0x80000000L) == 0) /* non-negative */
-      return uval;
+   if ((uval & 0x80000000) == 0) /* no overflow */
+       return -(png_int_32)uval;
+   /* The following has to be safe; this function only gets called on PNG data
+    * and if we get here that data is invalid.  0 is the most safe value and
+    * if not then an attacker would surely just generate a PNG with 0 instead.
+    */
+   return 0;
 
    uval = (uval ^ 0xffffffffL) + 1;  /* 2's complement: -x = ~x+1 */
    return -(png_int_32)uval;