Bug 2517751 (CVE-2026-18090)

Summary:	CVE-2026-18090 gdk-pixbuf: CVE-2026-18090 gdk-pixbuf: heap out-of-bounds read in uncompress() via crafted ICNS RLE block
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	gtanzill, jbuscemi, 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 gdk-pixbuf. This vulnerability allows a remote attacker to cause a heap out-of-bounds read by providing a specially crafted Apple Icon Image (.icns) file. The uncompress() function, which handles RLE-encoded ICNS icon data, fails to validate the source buffer's boundaries during decompression. This can lead to a denial of service, where the application crashes, or to information disclosure, potentially revealing sensitive data from adjacent memory.	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:

Description OSIDB Bzimport 2026-08-18 10:38:01 UTC

Heap out-of-bounds read in =uncompress()= in =gdk-pixbuf/io-icns.c= (function
spans lines 192-246 in the current upstream tree). The function decompresses
RLE-encoded ICNS icon data but is never given a bound on the source buffer;
it loops until it has produced =size*size= decoded pixels, consuming however
many source bytes the RLE stream claims it needs, with no check that any of
the three per-iteration reads (the tag byte at =data[0]=, the repeat-value
byte at =data[1]=, or the run bytes at =data[i + 1]=) stays inside the block
that =load_resources()= computed for it. =load_icon()= holds the correct
block size (=isize=, derived from =load_resources()='s =plen = blocklen -
sizeof(IcnsBlockHeader)= calculation) but never forwards it to =uncompress()=.
A crafted =.icns= file with a truncated RLE block (e.g. an =il32= block whose
declared =blocklen= only covers the header, with zero payload bytes) causes
=uncompress()= to read past the end of the mapped/allocated ICNS data,
an out-of-bounds heap read that can crash the process or leak adjacent heap
bytes into the decoded pixel data. All four RLE-compressed ICNS block types
(=is32= 16x16, =il32= 32x32, =ih32= 48x48, =it32= 128x128) are affected; the
=ic08=/=ic09= (256x256) blocks use JPEG 2000, not this decompressor, and are
not affected.