Imager::File::PNG versions from 1.003 before 1.004 for Perl write past the end of the row buffer reading a PNG with a tRNS transparency chunk in readdirect8.

With a tRNS chunk, readdirect8() adds an alpha channel to the image it creates but still sizes the row buffer from the original channel count. libpng expands the transparency into that extra channel, so pngreadrow() fills one channel more than the buffer holds, at one byte per sample, and writes width bytes past the end of the allocation. Palette images go to readpaletted() and 16-bit images to readdirect16(), which sizes its buffer from pnggetrowbytes() and allocates enough for the expanded row.

The same reader ships bundled in the Imager distribution.

Reading an attacker-supplied PNG through Imager->read() corrupts the heap, which can crash the process.

Imager versions from 0.4502 before 1.034 for Perl may expose adjacent heap bytes via strlen() over-read from zero-count ASCII EXIF entries in copystringtags.

copystringtags() computes an ASCII EXIF tag's length as entry->size - 1 to strip the trailing NUL. A zero-count ASCII entry sets entry->size to 0, and the derived length reaches itagsadd() as -1, which is interpreted as a request to call strlen(), scanning past the entry to the next NUL and copying those bytes into the tag. JPEG reaches this path via imdecodeexif(), as does the separate Imager::File::WEBP distribution, which is fixed by upgrading Imager.

Any caller of Imager->read() on an attacker-supplied image with such an entry may receive an exif tag holding adjacent heap bytes instead of an empty string.

Imager versions before 1.033 for Perl treat unsigned EXIF IFD entry counts as signed.

Imager mishandled large EXIF IFD entry count values, treating them as negative numbers. This could lead to an attempt to allocate a block nearly the size of the address space, which fails and kills the process.

An attacker could craft an image with EXIF data that terminates a worker process.

Imager versions before 1.032 for Perl have a heap out-of-bounds read in the bundled Imager::File::SGI reader via a 16-bit RLE literal run in readrgb16rle.

readrgb16rle guards each literal run with if (count > dataleft), but count is a pixel count while every 16-bit sample consumes two bytes. The copy loop reads inp[0] 256 + inp[1] and advances two bytes per pixel, so a run with dataleft / 2 < count <= dataleft passes the guard yet consumes 2 count bytes and reads past the end of the buffer. The 8-bit path is unaffected because there one pixel is one byte.

Reading a crafted SGI image through Imager->read triggers the over-read before the parser rejects the malformed image, which can crash the process.

Buffer overflow in Imager 0.42 through 0.63 allows attackers to cause a denial of service (crash) via an image based fill in which the number of input channels is different from the number of output channels.