An issue was discovered in libsixel 1.8.2. There is a heap-based buffer overflow in the function sixeldecoderawimpl at fromsixel.c.

An issue was discovered in libsixel 1.8.2. There is an integer overflow in the function sixeldecoderawimpl at fromsixel.c.

An issue was discovered in libsixel 1.8.2. There is an integer overflow in the function sixelencodebody at tosixel.c.

An issue was discovered in libsixel 1.8.2. There is a heap-based buffer overflow in the function loadpnm at frompnm.c, due to an integer overflow.

libsixel 1.8.4 has an integer overflow in sixelframeresize in frame.c.

An issue was discovered in libsixel 1.8.4. There is a heap-based buffer overflow in the function gifoutcode at fromgif.c.

An issue was discovered in libsixel 1.8.4. There is a heap-based buffer overflow in the function gifinitframe at fromgif.c.

An issue was discovered in libsixel 1.8.2. There is a heap-based buffer over-read in the function loadsixel at loader.c.

stbimage.h (aka the stb image loader) 2.23, as used in libsixel and other products, has a heap-based buffer over-read in stbiloadmain.

Libsixel 1.8.3 contains a heap-based buffer overflow in the sixelencodehighcolor function in tosixel.c.

Libsixel 1.8.2 contains a heap-based buffer overflow in the ditherfuncfs function in tosixel.c.

libsixel 1.8.6 suffers from a Heap Use After Free vulnerability in in libsixel/src/dither.c:388.

libsixel 1.8.6 is affected by Buffer Overflow in libsixel/src/quant.c:876.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. In versions 1.8.7 and prior, when built with the --with-gdk-pixbuf2 option, a use-after-free vulnerability exists in loadwithgdkpixbuf() in loader.c. The cleanup path manually frees the sixelframet object and its internal buffers without consulting the reference count, even though the object was created via the refcounted constructor sixelframenew() and exposed to the public callback. A callback that calls sixelframeref(frame) to retain a logically valid reference will hold a dangling pointer after sixelhelperloadimagefile() returns, and any subsequent access to the frame or its fields triggers a use-after-free confirmed by AddressSanitizer. The root cause is a consistency failure between two cleanup strategies in the same codebase: sixelframeunref() is used in loadwithbuiltin() but raw free() is used in loadwithgdkpixbuf(). An attacker supplying a crafted image to any application built against libsixel with gdk-pixbuf2 support can trigger this reliably, potentially leading to information disclosure, memory corruption, or code execution. This issue has been fixed in version 1.8.7-r1.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. From to 1.8.7-r1, signed integer overflow in sixelencodehighcolor's allocation size calculation can lead to a heap buffer overflow. The public sixelencode entry point validates only that width and height are greater than zero, with no upper bound. width and height are multiplied as plain int when computing the allocation size for palettedpixels and normalizedpixels. Any caller that asks libsixel to encode a pixel buffer with width times height greater than INTMAX (about 2.15 billion) will hit a wrapped allocation size; under the right wrap, the malloc succeeds with a buffer much smaller than the encoder expects, and the encoder writes past the end of the heap allocation. This vulnerability is fixed in 1.8.7-r2.

In libsixel v1.8.2, there is a heap-based buffer over-read in the function loadjpeg() in the file loader.c, as demonstrated by img2sixel.

There is a heap-based buffer overflow at fromsixel.c (function: imagebufferresize) in libsixel 1.8.2 that will cause a denial of service or possibly unspecified other impact.

libsixel 1.8.1 has a memory leak in sixeldecoderdecode in decoder.c, imagebufferresize in fromsixel.c, and sixeldecoderaw in fromsixel.c.

libsixel 1.8.1 has a memory leak in sixelallocatornew in allocator.c.

Buffer Overflow in the "sixelencoderencodebytes" function of Libsixel v1.8.6 allows attackers to cause a Denial of Service (DoS).

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. Versions 1.8.7 and prior contain a use-after-free vulnerability in sixelencoderencodebytes() because sixelframeinit() stores the caller-owned pixel buffer pointer directly in frame->pixels without making a defensive copy. When a resize operation is triggered, sixelframeconverttorgb888() unconditionally frees this caller-owned buffer and replaces it with a new internal allocation, leaving the caller with a dangling pointer. Any subsequent access to the original buffer by the caller constitutes a use-after-free, confirmed by AddressSanitizer. An attacker who controls incoming frames can trigger this bug repeatedly and predictably, resulting in a reliable crash with potential for code execution. This issue has been fixed in version 1.8.7-r1.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. Versions 1.8.7 and prior contain an integer overflow which leads to a heap buffer overflow via sixelframeconverttorgb888() in frame.c, where allocation size and pointer offset computations for palettised images (PAL1, PAL2, PAL4) are performed using int arithmetic before casting to sizet. For images whose pixel count exceeds INTMAX / 4, the overflow produces an undersized heap allocation for the conversion buffer and a negative pointer offset for the normalization sub-buffer, after which sixelhelpernormalizepixelformat() writes the full image data starting from the invalid pointer, causing massive heap corruption confirmed by ASAN. An attacker providing a specially crafted large palettised PNG can corrupt the heap of the victim process, resulting in a reliable crash and potential arbitrary code execution. This issue has been fixed in version 1.8.7-r1.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. Versions 1.8.7 and prior contain an integer overflow leading to an out-of-bounds heap read in the --crop option handling of img2sixel, where positive coordinates up to INTMAX are accepted without overflow-safe bounds checking. In sixelencoderdoclip(), the expression clipw + clipx overflows to a large negative value when clipx is INTMAX, causing the bounds guard to be skipped entirely, and the unclamped coordinate is passed through sixelframeclip() to clip(), which computes a source pointer far beyond the image buffer and passes it to memmove(). An attacker supplying a specially crafted crop argument with any valid image can trigger an out-of-bounds read in the heap, resulting in a reliable crash and potential information disclosure. This issue has been fixed in version 1.8.7-r1.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. From to 1.8.7-r1, a signed integer overflow in the SIXEL parser's image-buffer doubling loop can lead to an out-of-bounds heap write in sixeldecoderawimpl. context->posx grows by repeatcount on every sixel character with no upper bound check. Once posx approaches INTMAX, the expression "posx + repeatcount" used to size the image buffer overflows signed int. Depending on how the overflow wraps, the resize check that should reject oversized buffers can be bypassed, after which a subsequent write computes a large attacker-influenced offset into image->data and writes past the allocation. Reachable from any caller that decodes attacker-supplied SIXEL data, including img2sixel. This vulnerability is fixed in 1.8.7-r2.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. Versions 1.8.7 and prior contain a Use-After-Free vulnerability via the loadgif() function in fromgif.c, where a single sixelframet object is reused across all frames of an animated GIF and gifinitframe() unconditionally frees and reallocates frame->pixels between frames without consulting the object's reference count. Because the public API explicitly provides sixelframeref() to retain a frame and sixelframegetpixels() to access the raw pixel buffer, a callback following this documented usage pattern will hold a dangling pointer after the second frame is decoded, resulting in a heap use-after-free confirmed by ASAN. Any application using sixelhelperloadimagefile() with a multi-frame callback to process user-supplied animated GIFs is affected, with a reliable crash as the minimum impact and potential for code execution. This issue has been fixed in version 1.8.7-r1.

An invalid memory address dereference was discovered in loadpnm in frompnm.c in libsixel before 1.8.3.

A memory leak was discovered in imagebufferresize in fromsixel.c in libsixel 1.8.4.

A heap-based buffer overflow was discovered in imagebufferresize in fromsixel.c in libsixel before 1.8.4.

An invalid read in the stbimage.h component of libsixel prior to v1.8.5 allows attackers to cause a denial of service (DOS) via a crafted PSD file.

Libsixel prior to v1.8.3 contains a stack buffer overflow in the function gifprocessraster at fromgif.c.