Security Advisories (10)
CVE-2016-1238 (2016-08-02)

Imager would search the default current directory entry in @INC when searching for file format support modules.

CVE-2008-1928 (2008-04-24)

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.

CVE-2007-2459 (2007-05-02)

Heap-based buffer overflow in the BMP reader (bmp.c) in Imager perl module (libimager-perl) 0.45 through 0.56 allows remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via crafted 8-bit/pixel compressed BMP files.

CPANSA-Imager-2014-01 (2014-01-03)

When drawing on an image with an alpha channel where the source minimum is greater than zero, Imager would read from beyond the end of a malloc() allocated buffer. In rare circumstances this could lead to some of the source image not being written to the target image, or possibly to a segmentation fault.

CVE-2024-53901 (2024-11-17)

"invalid next size" backtrace on use of trim on certain images

CVE-2006-0053 (2006-04-10)

Imager (libimager-perl) before 0.50 allows user-assisted attackers to cause a denial of service (segmentation fault) by writing a 2- or 4-channel JPEG image (or a 2-channel TGA image) to a scalar, which triggers a NULL pointer dereference.

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.

CVE-2026-19082 (2026-08-07)

Imager versions from 0.45_02 before 1.034 for Perl may expose adjacent heap bytes via strlen() over-read from zero-count ASCII EXIF entries in copy_string_tags. copy_string_tags() 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 i_tags_add() 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 im_decode_exif(), 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.

NAME

Imager::regmach - documents the register virtual machine used by Imager::transform2().

SYNOPSIS

The register machine is a complete rewrite of the stack machine orginally used by Imager::transform(), written for use by Imager::transform2().

DESCRIPTION

(This document might be a little incoherent.)

The register machine is a fast implementation of a small instruction set designed for evaluating an arithmetic expression to produce a colour for an image.

The machine takes as input:

instructions

An array of instructions

numeric registers

An array of numeric registers. Some registers are initialized as literals.

colour registers

An array of colour registers. Currently these registers aren't initialized.

input images

An array of Imager i_img pointers. The getpn operators read pixels from these images.

The instructions supplied each take up to 4 input numeric or colour registers with a single output numeric or colour register. The machine attempts to execute instructions as safely as possible, assuming that correct instructions have been provided, eg. the machine protects against divide by zero, but doesn't check register numbers for validity.

The final instruction must be a 'ret' instruction, which returns the result ;)

Adding new instructions

To add a new instruction:

  1. Add a new opcode to the enumeration in regmach.h - make sure to add comment after the enum name giving the input registers (rX for numeric, pX for colour) that the instruction takes. These must be in the order that the instruction expects to take the. Put a letter (r or p) after -> to indicate the result type.

  2. Add a case to regmach.c that executes the instruction.

  3. make

The makefile should rebuild the Regops.pm file, and your new instruction will be added as a function.

If you want to add a single alternative instruction that might take different argument types (it must take the same number of parameters), create another instruction with that name followed by a p. The current expression parsers explicitly look for such instruction names.

Future directions

Conditional and non-conditional jumps to implement iteration. This will break the current optimizer in Imager::Expr (and the compilers for both expression compilers, for that matter.)

Complex arithmetic (Addi suggested this one). This would most likely be a separate machine. Otherwise we'll have a very significant performance loss.

WARNINGS

If you feed bad 'machine code' to the register machine, you have a good chance of a SIGSEGV.