Bug 2539602

Summary: CVE-2026-96546 gimp: gimp: one-byte out-of-bounds heap read in the uncompressed DDS loader [fedora-all]
Product: [Fedora] Fedora Reporter: Vladimir Vasilev <vvasilev>
Component: gimpAssignee: Nils Philippsen <nphilipp>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: jridky, nphilipp, phracek, zdohnal
Target Milestone: ---Keywords: Security, SecurityTracking
Target Release: ---Flags: fedora-admin-xmlrpc: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: {"flaws": ["e3a6a6c3-5a52-49e6-a9fd-5f22a92fb19a"]}
Fixed In Version: Doc Type: ---
Doc Text:
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:    
Bug Blocks: 2539601    

Description Vladimir Vasilev 2026-09-23 18:05:26 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

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.