CVE-2025-13032: Avast driver double-fetch exploited for kernel read/write on Windows 11

A technical writeup from safateam.com closes out the team's two-part investigation of CVE-2025-13032, a double-fetch vulnerability in a kernel driver that ships with Avast antivirus. The second post walks through how the bug was exploited on a fully updated Windows 11 machine at the time of the finding, converting a small parsing mistake into a kernel pool overflow and, from there, into an arbitrary kernel read/write primitive suited for local privilege escalation.

The bug: one length, fetched twice

According to the writeup, the driver accepts a _UNICODE_STRING structure from user mode. The kernel-side code probes the user buffer for readability, then reads the structure's Length field to size a PagedPool allocation made through ExAllocatePoolWithTag, and later consults the same field a second time to drive a memmove of the string data. Nothing forces the two reads to agree, because user memory can be modified between them.

To win the race, a second user-mode thread spins continuously, flipping the shared Length field between a small, safe value and a malicious one (the researchers use 0x1000), while the main thread hammers the vulnerable IOCTL. When the kernel happens to read the small value when allocating and the large value when copying, more bytes are written than were reserved. The researchers report that although the timing window is tight, it can be hit dependably after a bounded number of attempts. Crucially for exploitation, the attacker controls the allocation size, the overflow size and the content that spills out.

Picking a target in the paged pool

Because the overflow lands in the paged pool, the region of kernel memory used for objects and data that can be swapped to disk, the researchers had a broad choice of structures to corrupt. They explain that since Windows 10 19H1 the pool has been managed by the Segment Heap, whose LFH backend hands out small allocations at randomized slots while the VS backend serves larger ones first-fit, so each size class requires its own spray strategy.

The victim they settled on is the I/O Ring, Windows' facility for batching asynchronous file I/O from user mode through APIs such as CreateIoRing, BuildIoRingRegisterBuffers and SubmitIoRing. The I/O Ring object itself lives in non-paged pool, but the array of registered-buffer pointers it maintains, RegBuffers inside _IORING_OBJECT, is allocated in the paged pool, exactly matching the overflow. Registering N buffers produces an array of N eight-byte pointers, so the allocation size is directly user-controlled, which makes heap spraying precise. And because registered buffers are checked when registration happens and then trusted for later IoRingReadFile and IoRingWriteFile operations, corrupting a single pointer in that array is enough to steer kernel reads and writes toward an attacker-chosen address. The team cites earlier research published on windows-internals.com that used the same object to build a read/write primitive on Windows 11, which validated the approach before they relied on it.

A mitigation already shipped

The post carries a notable caveat: recent Windows builds have adopted user-mode accessors in the kernel and drivers, checking user pointers on every kernel access rather than trusting an earlier probe. That hardening, the researchers say, defeats the exploitation technique described in their writeup, so the demonstrated path depends on running a Windows version that predates the mitigation.

Why it matters

Antivirus products install some of the most exposed kernel code on a typical Windows machine: they parse untrusted, attacker-supplied input and hand the results to privileged drivers. A bug of this kind turns that exposure into a direct route from any local account to SYSTEM, which is exactly what malware operators want once they have a foothold. The writeup also shows that double-fetch flaws, a class documented for well over a decade, remain practical on contemporary systems when mitigations are absent, and it illustrates how operating system facilities built for performance, such as the I/O Ring's registered buffers, double as convenient exploitation primitives. For defenders the lesson is twofold: security software deserves the same scrutiny as the operating system it protects, and kernel hardening like user-mode accessors retires entire categories of technique rather than single bugs.