REDHAT-BUG-2539601: Low severity GIMP GIMP vulnerability
A one-byte out-of-bounds heap read flaw was found in GIMP's DDS image loader. In loadlayer(), the bit-reader unconditionally increments the input pointer and fetches the next byte whenever the current byte's bits are exhausted. After processing the final pixel of an uncompressed DDS image, this logic dereferences exactly one byte beyond the allocated pixel buffer. The issue occurs with ordinary well-formed uncompressed DDS files, including files produced by GIMP itself, and was confirmed with AddressSanitizer in GIMP 3.2.6. The same code remained present in the main and gimp-3-2 branches when reported, and all versions are reported as affected. In a normal non-instrumented build, the adjacent byte is read into a local variable after the final pixel and is not known to influence the decoded image. No information disclosure or code-execution primitive was demonstrated, and a crash would require the byte immediately following the allocation to be inaccessible. This issue is distinct from CVE-2026-42170, which concerns a separate pitch-overflow write in the same file. A patch was available, but no fixed release had been identified at the time of reporting.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Users or services that open uncompressed DDS images in GIMP are exposed, including when processing ordinary well-formed files produced by GIMP itself. The report states that all versions are affected.
What must an attacker provide to trigger the flaw?
They need to cause GIMP to load an uncompressed DDS image. The out-of-bounds read occurs after the final pixel is processed, without requiring a malformed DDS file.
Is this likely to be exploitable for code execution or data disclosure?
No information-disclosure or code-execution primitive was demonstrated. In normal non-instrumented builds, the extra byte is read into a local variable and is not known to affect the decoded image.
Can this cause GIMP to crash?
A crash requires the byte immediately after the pixel-buffer allocation to be inaccessible. The issue was confirmed under AddressSanitizer, but the report does not establish a reliable crash condition in normal builds.
What can be done if no fixed release is available?
A patch was available at the time of reporting, although no fixed release had been identified. Until a patched build is deployed, avoid opening untrusted uncompressed DDS files in GIMP where practical.