Bug 2539601 (CVE-2026-96546)

Summary: CVE-2026-96546 gimp: gimp: one-byte out-of-bounds heap read in the uncompressed DDS loader
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A one-byte out-of-bounds heap read flaw was found in GIMP's uncompressed DDS image loader. When a user opens an uncompressed DDS image, the file-dds plug-in performs an unconditional one-byte look-ahead after processing the final pixel. This may cause the plug-in to crash if the byte immediately following the pixel buffer is inaccessible; no information disclosure or code execution has been demonstrated.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2539602    
Bug Blocks:    

Description OSIDB Bzimport 2026-09-23 18:04:20 UTC 
A one-byte out-of-bounds heap read flaw was found in GIMP's DDS image loader. In load_layer(), 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.