Bug 2517751 (CVE-2026-18090) - CVE-2026-18090 gdk-pixbuf: CVE-2026-18090 gdk-pixbuf: heap out-of-bounds read in uncompress() via crafted ICNS RLE block
Summary: CVE-2026-18090 gdk-pixbuf: CVE-2026-18090 gdk-pixbuf: heap out-of-bounds read...
Keywords:
Status: NEW
Alias: CVE-2026-18090
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-18 10:38 UTC by OSIDB Bzimport
Modified: 2026-09-07 06:33 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.