Description

SAIL is a cross-platform library for loading and saving images with support for animation, metadata, and ICC profiles. Prior to 1.0.0, sail_codec_load_frame_v8_xbm() in src/sail-codecs/xbm/xbm.c allocates the decoded pixel buffer using the X11 one-byte-per-literal layout, but an X10 static short file causes the flat decode loop to write two file-controlled bytes per literal. When ceil(width/8) produces an odd row stride, the X10 literal count includes a padding byte for every row, but the destination has no space for those bytes, so loading the XBM through sail_load_from_file, sail_load_from_memory, or sail_start_loading_* produces a forward heap overwrite that scales with image height. The X11 static char path is not affected. The overwrite can corrupt process state, cause reliable crashes, and potentially enable code execution in a susceptible consuming application. This issue is fixed in version 1.0.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-17T20:16:52.550Z",
  "pubdate": "2026-09-17T20:16:52.550Z",
  "executiveSummary": "A heap-based buffer overflow vulnerability exists in the SAIL image loading library, specifically within the XBM codec implementation prior to version 1.0.0.\nThe vulnerability resides in the sail_codec_load_frame_v8_xbm() function in src/sail-codecs/xbm/xbm.c, where incorrect buffer size calculations occur during the processing of X10 static short formatted files.\nThe flaw stems from a discrepancy between the allocated buffer size, based on the X11 one-byte-per-literal layout, and the actual bytes written when processing X10 data that includes row padding.\nSuccessful exploitation allows an attacker to perform a forward heap overwrite that scales with the image's height, leading to process state corruption, service crashes, or potential arbitrary code execution.\nThe vulnerability affects any application utilizing SAIL to load image data from untrusted sources. There are no specific authentication or privilege requirements to trigger the vulnerability, as it is exploitable via malformed input files processed through functions such as sail_load_from_file or sail_load_from_memory.",
  "technicalDetails": "The root cause of this vulnerability is an integer-based calculation error in the sail_codec_load_frame_v8_xbm() function. When handling XBM files, the library identifies the variant (X10 or X11) to determine the layout of the pixel data.\nIn the X11 static char path, the codec correctly interprets the one-byte-per-literal layout. However, when an X10 static short file is parsed, the codec utilizes a flat decode loop that attempts to write two file-controlled bytes per literal into the destination buffer.\nThe allocation logic assumes an X11 layout, which does not account for the additional requirements of X10 data structures. Specifically, when the calculation ceil(width/8) results in an odd row stride, the X10 format introduces a padding byte for every row. Because the destination buffer is allocated without space for these extra padding bytes, the codec writes beyond the boundaries of the allocated heap memory.\nThe attack flow begins when an attacker provides a specially crafted X10 XBM file to an application linked against a vulnerable version of SAIL. As the application invokes sail_load_from_file, sail_load_from_memory, or related loading entry points, the codec parses the malformed X10 data. During the decoding phase, the function performs a linear write operation that exceeds the allocated buffer size. This creates a forward heap overflow, where the extent of the memory corruption is proportional to the total height of the image, as each row containing odd strides contributes to the out-of-bounds write.\nThis heap corruption can overwrite adjacent object metadata, function pointers, or data structures on the heap. An attacker capable of influencing the heap layout through memory shaping may achieve reliable code execution by overwriting control flow mechanisms or sensitive application state. In many cases, the immediate result is an unhandled exception or memory access violation leading to a crash. Because the flaw is intrinsic to the codec logic, it requires no interaction from the user other than triggering the image load, making it a critical risk for applications processing user-provided images."
}