Overkill — escalating to SYSTEM from inside a Wi-Fi chip's firmware.

Nicola Stauffer and Gürkan Gür (ZHAW, Switzerland) show that Windows privilege-escalation research has a blind spot: everyone scrutinises the kernel, almost nobody scrutinises the coprocessors sitting next to it. Their exploit chain, Overkill, starts inside the firmware of a MediaTek MT7925 Wi-Fi 7 chip (hundreds of millions of units shipped in 2025) and ends with a SYSTEM shell on the latest Windows 25H2. The point is not really "this one Wi-Fi chip is broken." It is that the boundary between a peripheral's firmware and the host kernel is, in practice, barely a boundary at all. This is a memory-safety and trust-boundary research disclosure; the vendor has published fixes. I describe the architecture and the idea, not the working exploit.

Post 26 of my Black Hat Asia 2026 series. The published white paper includes exact vulnerable code, offsets and shellcode. I'm intentionally not reproducing those; I explain what kind of boundary failed and why it matters.

1. Why look at a Wi-Fi chip at all

A modern PC is not one processor. It's a main CPU plus a growing list of coprocessors: GPUs, NPUs for AI acceleration, and communication modules for Wi-Fi and cellular. Each of these runs its own firmware, often on a small, closed-source microcontroller with few or no exploit mitigations like ASLR. They talk to the host over well-understood buses, commonly PCIe, using memory-mapped I/O (MMIO) and DMA.

Security research has spent two decades hardening the kernel and user-space software. The "sub-OS" layer, where a host driver hands control to proprietary firmware on a peripheral, gets comparatively little scrutiny, and even less on Windows than on Linux. Wi-Fi is a natural target to study here: it's ubiquitous, tightly coupled to the OS for performance, and, by the authors' estimate, over two billion Wi-Fi 7 devices are expected to ship by 2028. A vulnerability at this layer doesn't stay contained to one machine's network card, it potentially reaches the very kernel that everything else on the system trusts.

2. The trust model that breaks

The implicit assumption in most driver code is that the device tells the truth. A network card reports statistics, calibration data, and asynchronous events, and the driver parses and stores them. That parsing code is written the same way any other input-handling code should be: defensively. In practice, code that processes device-originated data is often held to a lower bar than code that processes network- or user-originated data, because "it's our own hardware" feels safer than "it's the internet." Overkill's core argument is that this feeling is unjustified: if an attacker can run code on the coprocessor, or manipulate what it sends, the device becomes exactly as adversarial as any remote attacker, just with a much more trusted position in the architecture.

3. The shape of the attack chain, without the exploit

Rather than reproduce the working chain, here is the category of each step, which is the useful part for other researchers and defenders:

1. An out-of-bounds read in the host driver, reachable via a documented device-control interface, was used to leak an address related to the driver's own location in kernel memory. The bug involved a race between concurrent requests, not a single buffer overflow.
2. A timing side-channel (a known class of attack, previously demonstrated against Windows kernel address-space layout randomisation) was adapted to work on a different CPU vendor than it was originally built for, by first narrowing the range of addresses to test using the leak from step 1.
3. A memory-mapped I/O read/write primitive exposed by the driver, intended for legitimate low-level chip access, was used to reach into the coprocessor's own memory space and place code in a region that turned out to be writable and executable.
4. An unauthenticated, unsolicited event path: the Windows driver accepts certain event types from the device without requiring that the host had previously requested anything. One such event-handling function had a bounds-checking gap when copying attacker-controlled data reported by the device.
5. Chaining these gave the authors a way to corrupt a specific kernel value related to a Windows privilege check, escalating an ordinary process to SYSTEM.

Every step here is a well-known bug class: race-condition information leak, side-channel KASLR bypass, an over-permissive read/write primitive, and a missing bounds check on attacker-controlled length. What makes the chain notable is where they were found, entirely on the periphery of the system, several hops away from anything a typical kernel security review would touch.

4. Why this is more than "one buggy driver"

• Scale: hundreds of millions of units of this single chip family were manufactured in 2025 alone. A firmware-level bug in a component this widely deployed is not a niche finding.
• Blind spot, not exception: the authors frame this as symptomatic of an industry-wide pattern, not a one-off. Coprocessors for AI acceleration, graphics and connectivity all share the same characteristics: closed firmware, weak mitigations, and drivers written under an implicit trust assumption.
• Platform asymmetry: the same device family exists on Linux, where the analogous driver code has different (in places more defensive) event handling, illustrating that the vulnerability is not inherent to the chip so much as to how one OS's driver processes its output.
• Escalation from the "wrong" direction: most privilege-escalation research assumes an attacker already has local code execution and looks for kernel bugs directly reachable from user space. Here, the entry point is a peripheral that many threat models don't even consider part of the attack surface.

5. What should change

6. How this fits the rest of the series

This talk pairs naturally with two other entries here. The TraceLogging ETW talk showed how much of Windows' own telemetry is unexplored; Overkill shows the same is true of the trust Windows extends to hardware. And the underlying failure, a component that is supposed to just report data ends up able to corrupt state in a much more privileged component, is the same confused-deputy pattern behind the macOS PID-domain research, just crossing a hardware/software line instead of a process boundary.

Takeaways

• Windows privilege-escalation research overwhelmingly targets the kernel itself; coprocessor firmware is a comparatively unaudited path to the same outcome.
• Overkill chains a driver information leak, a side-channel KASLR bypass, an MMIO-based code-execution primitive on the Wi-Fi chip's own processor, and a missing bounds check in event parsing, to reach SYSTEM.
• The affected chip family shipped in the hundreds of millions of units in 2025 alone.
• The root cause is architectural: device-originated data is implicitly trusted by the host kernel in ways network- or user-originated data would never be.
• Fix: treat the firmware/kernel interface as an explicit security boundary, validate unsolicited device events as rigorously as network input, and extend mitigations to peripheral firmware.

References & further reading

• Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
• Official talk recording on YouTube — Black Hat channel.
• Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
• CVE-2025-20740 — the out-of-bounds read in the WLAN driver used for the initial leak.
• Microsoft: WifiCx driver model — the driver framework involved.
• Gruss et al., "Prefetch Side-Channel Attacks" (CCS 2016) — the foundational technique adapted in this research.