Description

A flaw was found in the file-iff (IFF/ILBM) plugin in GIMP. When processing a specially crafted IFF/ILBM image file, the plugin does not properly validate the HAM row size and improperly handles cases where the number of color planes (nPlanes) is zero. This causes a row size mismatch that bypasses memory bounds checking, resulting in heap out-of-bounds reads. This issue can result in an application crash, leading to a denial of service or a limited information disclosure of heap memory contents.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-08-28T16:18:33.933Z",
  "pubdate": "2026-08-28T16:18:33.933Z",
  "executiveSummary": "A heap-based out-of-bounds read vulnerability exists in the GIMP file-iff plugin, specifically affecting the processing of IFF/ILBM image files. The flaw arises from insufficient validation of HAM row size and improper handling of nPlanes (number of color planes) when the value is set to zero.\nThis vulnerability allows a remote attacker to trigger a heap memory corruption event by supplying a specially crafted image file. Successful exploitation typically results in an application crash, facilitating a denial-of-service (DoS) condition. Furthermore, the out-of-bounds read capability provides a vector for limited information disclosure, potentially exposing sensitive heap memory contents to the attacker.\nThe vulnerability does not require authenticated access, as it is triggered during the standard file parsing routine. The risk is classified as moderate, primarily constrained by the necessity of providing a malicious file to an unsuspecting user or automated system that utilizes the GIMP library for image processing. No specific privilege elevation is required beyond the user executing the application.",
  "technicalDetails": "The vulnerability resides within the GIMP file-iff plugin, which is responsible for parsing and rendering Interchange File Format (IFF) and Interleaved Bitmap (ILBM) files. The root cause is a deficiency in input sanitization logic during the parsing of image metadata, specifically involving the calculation of memory requirements for image rows.\nWhen the plugin processes an IFF/ILBM file, it must determine the size of the row buffer based on the image's dimensions and the number of color planes. The logic fails to account for scenarios where nPlanes is defined as zero. By submitting a crafted file where nPlanes is null, the parser incorrectly calculates the row buffer dimensions. This miscalculation creates a discrepancy between the allocated heap buffer size and the memory access range expected by the rendering loop.\nFurthermore, the validation mechanism for HAM (Hold-And-Modify) row size is inadequate. In HAM mode, pixels are rendered using a combination of direct values and modifications to existing color registers. If the row size logic is improperly constrained, the software proceeds to perform read operations based on the malformed metadata values. Because the bounds checking mechanisms rely on these inaccurate dimensions, the execution pointer or memory read offset moves outside the allocated heap memory block.\nThe attack flow proceeds as follows: 1) The attacker creates a malicious IFF file containing crafted headers where nPlanes is set to zero and/or HAM-specific parameters are designed to overflow the internal buffer calculations. 2) The victim opens this file in GIMP, or an automated service uses the GIMP plugin to process the file. 3) The plugin attempts to allocate memory or access the buffer based on the malicious metadata. 4) The application performs an out-of-bounds heap read, either causing a segmentation fault (DoS) or returning adjacent heap data to the application's processing output. This potentially leaks sensitive information present in the process heap to the attacker, depending on how the application handles the return data from the corrupted parsing routine.\nThis vulnerability is particularly concerning in environments where image parsing is automated, as it removes the need for user interaction to trigger the exploit, provided the system automatically processes untrusted incoming IFF files."
}