Avast Sandbox Driver Flaw: How a Double Fetch Led to System Privileges

SAFA Team published the second and final part of its Avast Antivirus research on Sept. 25, 2026, detailing exploitation of CVE-2025-13032, a double-fetch flaw in Avast's kernel driver. The write-up closes a series that began with its sandbox analysis late last year. SAFA Team

NVD records CVE-2025-13032 as affecting Avast and AVG Antivirus versions before 25.3 on Windows. It describes a double fetch in the sandbox kernel driver that allows a local attacker to escalate privileges through a pool overflow, with Attack Vector: Local. NVD

That driver context sets the scope. SAFA's earlier work studied the aswSnx kernel driver, and the team said it found four distinct kernel heap overflow vulnerabilities in Avast Antivirus during that research. Part 2 narrows from that set to a single flaw and a full exploitation path. SAFA Part 1

SAFA states it exploited the flaw on an up-to-date Windows 11 system at the time of discovery. The stated goal was to create an arbitrary kernel read and write primitive, the ability to read and change any kernel memory, and then achieve local privilege escalation.

How the double fetch becomes an overflow

At the core is a user-supplied _UNICODE_STRING, a Windows structure for holding text, and its Length field. The driver reads Length once to size a memory allocation with ExAllocatePoolWithTag, then reads it again to size a memmove copy into that buffer. If the value changes between reads, the copy no longer fits the allocation.

That is a classic time-of-check to time-of-use race, often called TOCTOU, where check and use see different values because the input changed in between. The allocation occurs in kernel context. The Length value lives in user-controlled memory. The driver trusts it twice.

SAFA's method for winning the race is direct. One thread calls the vulnerable IOCTL, the channel programs use to talk to the driver, in a tight loop. A second thread toggles Length between a small safe value and a large value, cited as 0x1000 in the write-up. The window is tight, and repetition makes success reliable.

When the first read sees the small value and the second sees the large value, memmove writes past the end of the buffer. The result is a kernel pool overflow with attacker-influenced size and data.

From overflow to kernel read and write

SAFA describes the overflow as targeting PAGED_POOL, a general area of kernel memory, with control over allocation size, overflow size, and content. That control permits heap layout manipulation, precise corruption of an adjacent pool object, and shaping of the corrupted fields. The stated endpoint was arbitrary kernel read and write, followed by local privilege escalation.

The team does not present this as a remote attack. The chain assumes code execution on the host with the ability to open the driver interface, issue IOCTLs, race user memory, and spray pool with chosen patterns. That matches the Local vector noted by NVD.

SAFA also notes that current Windows kernels and drivers use user-mode accessors to verify each kernel access to user-mode memory, which blocks the technique described here. The specific double-fetch pattern does not work on a kernel with that revalidation. The corrective practice is to capture user-supplied lengths and pointers once into kernel-owned storage and validate that copy, since any second read of the user address reopens the race.

In my view, the broader context goes beyond one antivirus driver. We have seen TOCTOU issues of this shape for years across vendors, and they tend to return where skipping a copy looks faster. The benefit here is the complete chain, from Length toggle to pool control to read and write to escalation on a modern Windows 11 target, plus a clear note on where accessor checks stop it. That gives defenders and driver developers a concrete pattern to search for and a concrete fix to verify, which over time can leave fewer of these local paths open.