kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/graphics/png/patches/patch-ac

49 lines
1.9 KiB
Text
Raw Normal View History

Fix another bug in png_do_read_filler() regarding 16-big *grayscale* images (and bump package to 1.2.5nb2). The following is taken directly from the png-implement mailing list... Date: Fri, 20 Dec 2002 11:26:31 -0500 From: Glenn Randers-Pehrson <glennrp@comcast.net> Reply-To: png-implement@ccrc.wustl.edu To: png-implement@ccrc.wustl.edu Subject: Re: [png-implement] bug in png_read_filler() with 16-bit samples At 01:01 AM 12/5/02 -0500, Glenn Randers-Pehrson wrote: >A bug has turned up in png_read_filler() with 16-bit samples. >The starting offsets for the loops are calculated incorrectly >which causes a buffer overrun beyond the beginning of the row >buffer. > >To fix, at lines 1968 and 1990, >change "row_width * 3" to "row_width * 6" >and at lines 1969 and 1991, >change "row_width;" to "row_width * 2;" This is only half of the story. Adding an alpha channel to 16-bit *grayscale* images with png_do_read_filler() exhibits the same bug, and pngcrush crashes if I try to do it. To fix, at lines 1892, 1893, 1910, and 1911 of pngrtran.c change "row_width" to "row_width * 2" Note that applications that do not add an alpha channel via png_set_filler(), and any applications that do, but reduce 16-bit samples to 8 bit via png_set_strip_16() are invulnerable to the bug. Pngcrush is the only application that I know of that uses png_set_filler() without also using png_set_strip_16(). Glenn -- Send the message body "help" to png-implement-request@ccrc.wustl.edu
2002-12-20 18:54:27 +01:00
$NetBSD: patch-ac,v 1.2 2002/12/20 17:54:28 fredb Exp $
Fix a buffer overrun in png_do_read_filler() with 16-bit samples, as reported to the png-implement mailing list by Glenn Randers-Pehrson: ftp://swrinde.nde.swri.edu/pub/png-group/archives/png-implement.200212 [Glenn Randers-Pehrson is the original author and chief maintainer of libpng.] From the discussion in the archive, it appears to be unlikely that the bug could be exploited by a malicious web-server, chiefly because the operation that triggers it is more likely to be carried out by an image manipulation program (i.e. pngcrush), than by a web browser.
2002-12-19 22:25:09 +01:00
--- pngrtran.c.orig Thu Oct 3 06:32:29 2002
+++ pngrtran.c
Fix another bug in png_do_read_filler() regarding 16-big *grayscale* images (and bump package to 1.2.5nb2). The following is taken directly from the png-implement mailing list... Date: Fri, 20 Dec 2002 11:26:31 -0500 From: Glenn Randers-Pehrson <glennrp@comcast.net> Reply-To: png-implement@ccrc.wustl.edu To: png-implement@ccrc.wustl.edu Subject: Re: [png-implement] bug in png_read_filler() with 16-bit samples At 01:01 AM 12/5/02 -0500, Glenn Randers-Pehrson wrote: >A bug has turned up in png_read_filler() with 16-bit samples. >The starting offsets for the loops are calculated incorrectly >which causes a buffer overrun beyond the beginning of the row >buffer. > >To fix, at lines 1968 and 1990, >change "row_width * 3" to "row_width * 6" >and at lines 1969 and 1991, >change "row_width;" to "row_width * 2;" This is only half of the story. Adding an alpha channel to 16-bit *grayscale* images with png_do_read_filler() exhibits the same bug, and pngcrush crashes if I try to do it. To fix, at lines 1892, 1893, 1910, and 1911 of pngrtran.c change "row_width" to "row_width * 2" Note that applications that do not add an alpha channel via png_set_filler(), and any applications that do, but reduce 16-bit samples to 8 bit via png_set_strip_16() are invulnerable to the bug. Pngcrush is the only application that I know of that uses png_set_filler() without also using png_set_strip_16(). Glenn -- Send the message body "help" to png-implement-request@ccrc.wustl.edu
2002-12-20 18:54:27 +01:00
@@ -1889,8 +1889,8 @@
/* This changes the data from GG to GGXX */
if (flags & PNG_FLAG_FILLER_AFTER)
{
- png_bytep sp = row + (png_size_t)row_width;
- png_bytep dp = sp + (png_size_t)row_width;
+ png_bytep sp = row + (png_size_t)row_width * 2;
+ png_bytep dp = sp + (png_size_t)row_width * 2;
for (i = 1; i < row_width; i++)
{
*(--dp) = hi_filler;
@@ -1907,8 +1907,8 @@
/* This changes the data from GG to XXGG */
else
{
- png_bytep sp = row + (png_size_t)row_width;
- png_bytep dp = sp + (png_size_t)row_width;
+ png_bytep sp = row + (png_size_t)row_width * 2;
+ png_bytep dp = sp + (png_size_t)row_width * 2;
for (i = 0; i < row_width; i++)
{
*(--dp) = *(--sp);
@@ -1965,8 +1965,8 @@
Fix a buffer overrun in png_do_read_filler() with 16-bit samples, as reported to the png-implement mailing list by Glenn Randers-Pehrson: ftp://swrinde.nde.swri.edu/pub/png-group/archives/png-implement.200212 [Glenn Randers-Pehrson is the original author and chief maintainer of libpng.] From the discussion in the archive, it appears to be unlikely that the bug could be exploited by a malicious web-server, chiefly because the operation that triggers it is more likely to be carried out by an image manipulation program (i.e. pngcrush), than by a web browser.
2002-12-19 22:25:09 +01:00
/* This changes the data from RRGGBB to RRGGBBXX */
if (flags & PNG_FLAG_FILLER_AFTER)
{
- png_bytep sp = row + (png_size_t)row_width * 3;
- png_bytep dp = sp + (png_size_t)row_width;
+ png_bytep sp = row + (png_size_t)row_width * 6;
+ png_bytep dp = sp + (png_size_t)row_width * 2;
for (i = 1; i < row_width; i++)
{
*(--dp) = hi_filler;
Fix another bug in png_do_read_filler() regarding 16-big *grayscale* images (and bump package to 1.2.5nb2). The following is taken directly from the png-implement mailing list... Date: Fri, 20 Dec 2002 11:26:31 -0500 From: Glenn Randers-Pehrson <glennrp@comcast.net> Reply-To: png-implement@ccrc.wustl.edu To: png-implement@ccrc.wustl.edu Subject: Re: [png-implement] bug in png_read_filler() with 16-bit samples At 01:01 AM 12/5/02 -0500, Glenn Randers-Pehrson wrote: >A bug has turned up in png_read_filler() with 16-bit samples. >The starting offsets for the loops are calculated incorrectly >which causes a buffer overrun beyond the beginning of the row >buffer. > >To fix, at lines 1968 and 1990, >change "row_width * 3" to "row_width * 6" >and at lines 1969 and 1991, >change "row_width;" to "row_width * 2;" This is only half of the story. Adding an alpha channel to 16-bit *grayscale* images with png_do_read_filler() exhibits the same bug, and pngcrush crashes if I try to do it. To fix, at lines 1892, 1893, 1910, and 1911 of pngrtran.c change "row_width" to "row_width * 2" Note that applications that do not add an alpha channel via png_set_filler(), and any applications that do, but reduce 16-bit samples to 8 bit via png_set_strip_16() are invulnerable to the bug. Pngcrush is the only application that I know of that uses png_set_filler() without also using png_set_strip_16(). Glenn -- Send the message body "help" to png-implement-request@ccrc.wustl.edu
2002-12-20 18:54:27 +01:00
@@ -1987,8 +1987,8 @@
Fix a buffer overrun in png_do_read_filler() with 16-bit samples, as reported to the png-implement mailing list by Glenn Randers-Pehrson: ftp://swrinde.nde.swri.edu/pub/png-group/archives/png-implement.200212 [Glenn Randers-Pehrson is the original author and chief maintainer of libpng.] From the discussion in the archive, it appears to be unlikely that the bug could be exploited by a malicious web-server, chiefly because the operation that triggers it is more likely to be carried out by an image manipulation program (i.e. pngcrush), than by a web browser.
2002-12-19 22:25:09 +01:00
/* This changes the data from RRGGBB to XXRRGGBB */
else
{
- png_bytep sp = row + (png_size_t)row_width * 3;
- png_bytep dp = sp + (png_size_t)row_width;
+ png_bytep sp = row + (png_size_t)row_width * 6;
+ png_bytep dp = sp + (png_size_t)row_width * 2;
for (i = 0; i < row_width; i++)
{
*(--dp) = *(--sp);
Reference in a new issue Copy permalink