Back
CVE-2025-13032 Part 2: SAFA shows a full Windows 11 privilege escalation through Avast's driver
SiTech AI Team2 წთ. საკითხავი

CVE-2025-13032 Part 2: SAFA shows a full Windows 11 privilege escalation through Avast's driver

SAFA Team has detailed how it turned CVE-2025-13032, a double-fetch bug in Avast's kernel driver, into a full local privilege escalation to SYSTEM on an up-to-date Windows 11 machine. The flaw has since been patched.

SAFA Team has published the second and final part of its research into CVE-2025-13032, a double-fetch vulnerability it found in Avast's kernel driver. The post, dated September 18, 2026, describes a complete exploit chain that reaches SYSTEM privileges on a fully updated Windows 11 system.

From a double fetch to a pool overflow

The driver captures a user-supplied _UNICODE_STRING but reads its Length field twice: first to size a buffer through ExAllocatePoolWithTag, then to drive the memmove that copies the string into it. A second thread can flip Length to a large value such as 0x1000 between those reads, while the main thread keeps calling the vulnerable IOCTL. When the timing lines up, the kernel copies more bytes than it allocated and overflows the next chunk of paged pool. SAFA says the race window is narrow but winnable.

Targeting the IORing RegBuffers array

The target was the I/O Ring object, which batches asynchronous file operations through IoRingReadFile and IoRingWriteFile. Its RegBuffers pointer array sits in paged pool, its size is user-controlled, and corrupting a single pointer is enough for a full read/write primitive. The team sprayed many such arrays, freed some and triggered the bug so that a corrupted chunk landed next to a live one.

Schematic of the RegBuffers array

RegBuffers[0] was redirected to a fake _IOP_MC_BUFFER_ENTRY in the attacker's memory, so the kernel dereferences a userland address under his control. That works because Windows does not implement SMAP. IoRingReadFile became an arbitrary kernel write and IoRingWriteFile an arbitrary kernel read.

Leaking a kernel address through an MDL

Kernel addresses are randomised, so the exploit needed one known address: its own _EPROCESS. A registered buffer is mapped through a Memory Descriptor List, whose pointer the kernel stores in the buffer entry. Since that entry now lives in userland, the researchers read the Mdl field, pointed Address at the MDL and read the Process field, which points to the owning _EPROCESS.

Repairs, then SYSTEM via token theft

The overflow had also damaged ProcessBilled, an obfuscated pointer in the pool chunk header computed as EPROCESS ^ ChunkAddress ^ ExpPoolQuotaCookie; uncorrected, it crashes the machine on free. SAFA derived the cookie from a second, clean IORing object and wrote the value back. The final step steals the SYSTEM process token: the exploit walks the EPROCESS list, reads SYSTEM's token and overwrites its own. SAFA says the flaw has since been patched, and newer Windows kernels use user-mode accessors that would block this technique.

SSiTech

SiTech — AI-powered web development

We build fast, modern websites and bring AI into real business workflows. Have a project or a question? We'd love to help.