CVE-2025-49733
win32k.sys -- use-after-free in ICOMP component allows elevation of privilege
Summary
| Field | Value |
|---|---|
| Driver | win32k.sys (Win32K - ICOMP) |
| Vulnerability Class | Use-After-Free |
| CVSS | 7.8 |
| Exploited ITW | No |
| Patch Date | July 8, 2025 |
Root Cause
The Win32K ICOMP (Image Composition) component manages graphical objects that participate in rendering optimization within the Windows display subsystem. This vulnerability, patched alongside the ICOMP double-free in CVE-2025-49667, targets a different but related flaw in how ICOMP tracks object lifetimes.
When graphical objects are destroyed through certain API sequences, the ICOMP component frees an internal object while another code path still holds a reference to it. The destruction sequence that triggers this is specific: it involves objects with composition dependencies where one object's destruction does not properly notify all referencing paths. The stale reference persists, and when it is eventually dereferenced, it accesses memory that has been returned to the free list.
Unlike the double-free in CVE-2025-49667, this is a classical use-after-free where the object is freed once but accessed afterward. The two vulnerabilities in ICOMP being patched in the same cycle suggests Microsoft found them during a focused audit of the component's object lifecycle management.
Exploitation
The attacker triggers the UAF by creating graphical objects with specific composition relationships and then destroying them in a sequence that leaves a dangling reference. After the free occurs, the attacker sprays the kernel heap to reclaim the freed allocation with controlled data.
When the stale reference is dereferenced, the ICOMP code operates on the attacker's data as though it were a legitimate graphical object. The fake object's fields can be crafted to redirect function pointers or corrupt adjacent data structures, yielding a kernel memory corruption primitive. Standard token manipulation completes the chain to SYSTEM.
Exploitation Primitive
Graphical object creation/destruction sequence -> ICOMP object freed
-> stale reference persists -> heap reclaim
-> kernel corruption via fake object -> SYSTEM
Broader Significance
Two ICOMP vulnerabilities patched in the same cycle (this one and CVE-2025-49667) point to a broader problem in the component's object lifecycle management. The ICOMP subsystem manages complex object graphs where destruction order matters, and it appears that not all destruction orderings were properly handled. This is a common pattern in graphics subsystems where object relationships create implicit assumptions about destruction sequencing.