CVE-2025-49667
win32k.sys -- double-free in ICOMP component via GDI/window management APIs
Summary
| Field | Value |
|---|---|
| Driver | win32k.sys (Win32K -- ICOMP component) |
| Vulnerability Class | Double Free |
| CVSS | 7.8 |
| Exploited ITW | No |
| Patch Date | July 8, 2025 |
Root Cause
The Win32K subsystem's ICOMP (Image Composition) component handles internal graphical composition for rendering optimization. It manages pools of graphical objects that are created, transformed, and destroyed in response to GDI and window management API calls from user-mode applications.
The vulnerability is a double-free. When graphical objects are destroyed through specific API call sequences, the ICOMP component loses track of an allocation's lifecycle state. The object gets freed once through the normal destruction path, but a second code path retains a reference and frees it again. This corrupts the kernel heap's free list metadata, leaving the allocator in an inconsistent state.
What makes this interesting from an exploitation perspective is that Win32K double-frees have a long history of being weaponizable. A public PoC is available on GitHub, and ZeroPath published a technical exploration of the vulnerability. The specific GDI API sequences needed to trigger the double-free involve creating objects, setting up composition relationships between them, and then destroying them in an order that the ICOMP component does not handle correctly.
Exploitation
The attacker first identifies the precise sequence of GDI API calls that triggers the double-free. This involves creating graphical objects with specific composition relationships and then destroying them to leave the ICOMP component in a confused state about which allocations are still live.
Once the double-free fires, the attacker reclaims the freed memory by spraying controlled data into the kernel heap. When the second free occurs, the heap metadata is corrupted in a way that the attacker can predict. By carefully controlling the contents of the reclaimed region, the attacker forges kernel objects that provide an arbitrary write primitive. From there, standard token manipulation yields SYSTEM.
Exploitation Primitive
GDI API sequence -> ICOMP object double-free -> heap corruption
-> spray controlled objects into freed region
-> forge kernel objects -> arbitrary write -> SYSTEM
Broader Significance
Win32K has been one of the most prolific sources of kernel vulnerabilities in Windows for over a decade. The ICOMP component adds a layer of complexity because it manages object lifetimes across multiple interdependent graphical elements. Double-frees in this context are particularly dangerous because the attacker controls the allocation and deallocation timing through user-mode GDI calls, giving precise control over heap state. The availability of a public PoC makes this a higher-priority patching target.