/ 
Imager-1.024_008
⭐ Starred 27 / Imager::Threads
Security Advisories (3)
CVE-2026-8669 (2026-05-15)

Imager versions through 1.030 for Perl allow a heap out of bounds (OOB) write on crafted multi-frame GIF files. Imager::File::GIF's i_readgif_multi_low allocates a single per-row buffer GifRow sized for the GIF's global screen width 'SWidth' and reuses it across every image in the file. The page-match branch validates Image.Width + Image.Left > SWidth before each DGifGetLine write, but the parallel skip-image branch at imgif.c:790-805 calls DGifGetLine(GifFile, GifRow, Width) with no such check.

CVE-2026-13705 (2026-07-06)

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 read_rgb_16_rle. read_rgb_16_rle guards each literal run with if (count > data_left), 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 data_left / 2 < count <= data_left 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.

CVE-2026-14454 (2026-07-08)

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.

NAME

Imager::Threads - Imager and threads

SYNOPSIS

use Imager;
use threads;
Imager->preload;

threads->create(...);

DESCRIPTION

Starting from version 0.94 Imager attempts to work safely with perl's ithreads.

Previous versions stored some state in global variables, in particular the internal error stack.

However there are some limitations:

  • Imager's debug malloc isn't thread safe and will never be. Imager's debug malloc is disabled by default.

  • libtiff, which Imager uses for TIFF file support is not thread safe, Imager::File::TIFF works around this by single-threading its access to libtiff.

  • giflib, which Imager uses for GIF support is not thread safe before version 5. Imager::File::GIF works around this by single threading its access to giflib.

  • T1Lib, used by one of Imager's font drivers, is not thread safe. Imager::Font::T1 works around this by single threading access.

  • killing a thread reading or writing TIFF or GIF files, or using T1 fonts through Imager::Font::T1 may deadlock other threads when they attempt to read or write TIFF or GIF files, or work with Type 1 fonts.

  • Fill, font, color or I/O layer objects created in one thread are not valid for use in child threads. If you manage to duplicate such an object in another thread, you get to keep both pieces when it breaks.

Note that if you have another module using libtiff, giflib or t1lib it may interact with Imager's use of those libraries in a threaded environment, since there's no way to co-ordinate access to the global information libtiff, giflib and t1lib maintain.

Imager currently doesn't use threads itself, except for testing its threads support.

SEE ALSO

Imager, threads

AUTHOR

Tony Cook <tony@cpan.org>