Finding new drivers vulnerable to CVE-2024-26507

Disclaimer

I disclosed all of this publicly: the tooling, the proof of concept, and the reports. The NVD entry for CVE-2024-26507 now lists this repository (PaulDotSH/vuln-driver-aida64) among its references. Some of the code and text was AI-assisted. I verified every finding, hash, IOCTL, and code path on a real Windows machine.

I did not report the original CVE. Another researcher found the AIDA64 kernel driver issue in early 2024 and got CVE-2024-26507 assigned (advisory at belong2yourself.github.io, PoC at klezVirus/AIDA64Driver-EoP). My work was to find additional vulnerable builds and versions that nobody had covered, verify them, and get them added to the existing record.

At a glance

| CVE | CVE-2024-26507 | | Class | Local privilege escalation via arbitrary physical memory R/W | | Weakness | CWE-1286 | | CVSS 3.1 | 7.8 (High) | | Vendor | FinalWire (AIDA64) |

Kernel exploit kits almost never are from a fresh kernel bug. They ship a signed driver that already does what the attacker wants, usually arbitrary physical or kernel memory read and write, and that an unprivileged process can drive with no check in between. A real vendor signed the driver, so it loads on a stock Windows box with Driver Signature Enforcement on. The attacker brings the driver and the kernel supplies the escalation.

The question I cared about was not whether I could write an exploit. It was which signed drivers have a dangerous primitive accessible by a normal user. That is a search problem, so I automated it.

One detail matters here. A CVE pins one version range, not every build. Vendors keep shipping the same flawed driver across releases, each signed with a fresh timestamp and a new hash. Enumerating those builds is useful work on its own, and it is what I ended up doing.

I have written a static analyzer in Python (drvscan) for Windows kernel drivers. It scores drivers against the pattern that makes BYOVD work, then I have a more detailed look at the found driver.

drvscan parses the PE headers, and has some weights based on the found signals. We also check if a device is created, since we only care for user mode reachability. We also count memory mapping, section mapping and others.

I have implemented a scraper for multiple web sources which I won't name, where I get the drivers from. The analysis is done on the downloaded drivers.

AIDA64 is FinalWire's system information and diagnostics utility. Its kernel component, kerneld.x64, ships as aida64x.sys with a second build as aida64.sys. FinalWire signs both and they load on stock Windows, including builds I pulled from current vendor packages. The triage report for the second build:

Output from my custom tool:

eba3233869c744271d5c22e4c1011ce866987d444a00bb78e4089637b7ed794b physical_memory, mdl_mapping, exposes_device \Device\AIDA64Driver, \DosDevices\AIDA64Driver e:\work\visualc\llkd\driver.nt\amd64\LLKD.pdb We see by these findings together a driver that creates a device object, maps physical memory, maps MDLs, and imports no access check.

The original 2024 report already described that shape. What I found was that the same defect sits in additional signed builds and versions, including ones in current 8.x AIDA64 packages, none of which were in the known-vulnerable record for the family.

The device object is the pivot. The driver creates \Device\AIDA64Driver from DriverEntry with no ACL, so any process can open it:

HANDLE h = CreateFileA("\\\\.\\AIDA64Driver",
                       GENERIC_READ | GENERIC_WRITE,
                       FILE_SHARE_READ | FILE_SHARE_WRITE,
                       NULL, OPEN_EXISTING, 0, NULL);

The driver then exposes IOCTLs that take a caller-supplied physical address and size and pass them through with no validation:

The bulk path is the standard kernel-to-user mapping chain. The handler reads the address and length from IRP->SystemBuffer and calls MmMapIoSpace, IoAllocateMdl, MmBuildMdlForNonPagedPool, and MmMapLockedPagesSpecifyCache in sequence, mapping the result into the caller's address space.

An unprivileged caller ends up with arbitrary physical memory read and write. With the token-stealing technique that h0mbre and Ruben Boonen have both written up, that is enough to reach NT AUTHORITY\SYSTEM without a memory-safety bug.

aida64_rw.c is built to prove it with a round trip instead of exposing a poke-any-address tool:

VirtualAlloc a large buffer, fill it with a 16-byte marker, and VirtualLock it so it stays resident. If the driver were not mapping real physical memory, the round trip would fail. It does not. I left the step from arbitrary physical read and write to kernel code execution or an EDR kill out of the PoC and this post. The point is to document the defect for the advisory process, not to ship a weapon.

To measure how usable the primitive is, I wrote a memflow connector, memflow-aida64, over the two METHOD_BUFFERED IOCTLs. It presents the driver as a memflow PhysicalMemory backend, so any memflow OS layer can run on top of it, which is full virtual memory access to the running OS from an unprivileged process. memflow-bench compares it against a raw IOCTL backend on per-call latency and on bulk throughput up to 4 MB.

I am not publishing the connector. Same reason as the PoC: defenders need to know the driver is dangerous, not to be handed a kernel memory access tool.

Everything is public.

belong2yourself.github.io, PoC at The binaries I reported:

The "lesson" here is not that I found a bug. Someone else found it and got the CVE. The lesson is that a CVE entry does not enumerate every affected build. The same signed physical-memory primitive kept shipping, and the original record did not cover it.

For anyone auditing: signing does not make a driver safe, and a diagnostics utility that maps physical memory for hardware information is one IOCTL away from local privilege escalation. Keep scanning after a CVE lands, because the fixed version in the record can be narrower than the vulnerable reality.