[HackerNotes Ep. 157] Kernel Driver Exploitation: MediaTek Wi-Fi Heap Overflow to Root Shell with Hypr

Hacker TL;DR

• Blind kernel exploitation without debuggers is feasible through deterministic trial-and-error and kernel source analysis

• ioctl handlers in legacy Linux drivers offer a massive attack surface, reachable from unprivileged user space, often without bounds checks

• modprobe_path overwrite remains the easiest kernel-to-userland execution primitive when arbitrary write is achieved

• Pwn2Own exploits can be hard to achieve, especially when you face ASLR, you're left brute-forcing address space alignment on unknown hardware configurations with limited attempts.

We do subs at $25, $10, and $5, premium subscribers get access to:

– Hackalongs: live bug bounty hacking on real programs, VODs available
– Live data streams
– Exploits, tools & scripts
– Un-redacted bug reports
– A collaborative hacking environment

Check out the CTBB Discord!

You can also find some hacker swag here.

The bug shared : MediaTek Wi-Fi Driver heap overflow (CVE-2025-2742)

How does this get started: WAPPD to Kernel

The journey started with a user-land daemon (WAPPD) back in 2023. This daemon, part of the MediaTek SDK, manages Wi-Fi configuration and maps network requests to ioctl calls. Hypr found a separate WAPPD vulnerability, wrote four exploits, then noticed: "There's another component I'm not seeing."

Companies like Netgear release GPL-licensed code archives. Netgear's archive accidentally included the full proprietary MediaTek driver source. Access to this code revealed the kernel-side handlers WAPPD was communicating with.

If WAPPD has bugs and WAPPD calls kernel ioctl handlers, kernel bugs become remotely exploitable through WAPPD as a bridge. Local privilege escalation chains into remote code execution when userland services proxy attacker input into kernel interfaces.

MediaTek code appears across devices, Netgear routers, Starlink terminals, consumer IoT products. A local privilege escalation on one platform becomes critical when the same driver runs in environments with different threat models.

The actual bug

MediaTek Wi-Fi kernel drivers expose a ioctl management interface for user-land daemons to configure wireless functionality. And the CVE-2025-2742 founds by Hypr represents a heap overflow triggered through this interface, a straightforward memory corruption primitive from user-land to kernel exploitation.

The vulnerability exists in structured data parsing. When user space initiates an ioctl call, the kernel receives a structure containing a pointer field and a size indicator. During the copy operation from user space to kernel structures, the size field determines how much data gets copied from embedded buffers. The critical flaw: missing bounds validation on this size field.

What makes this bug interesting is the size field type, a char, capped at 255 bytes maximum overflow. This constraint eliminates naive "write until you hit something" approaches and forces precision exploitation.

ioctl as Attack Surface

The ioctl API represents a deprecated but persistent interface for user space to send messages directly into kernel drivers. Modern kernel versions enforce stricter syscall permissions, but IoT devices run older kernels where fully unprivileged users can issue ioctl calls without authentication.

Each ioctl handler maps to a command code, an integer value dictating which handler processes the request. The attack surface becomes: which handlers are compiled in, which are reachable, and which accept attacker-controlled data without validation.

Hypr's enumeration approach: iterate hex 0x1000 through 0xFFFF, blast each code with large blocks of 0x41s, observe kernel behavior. This primitive fuzzing immediately revealed multiple bugs. The opaque nature of ioctl, arbitrary binary structures with no standardized format, makes comprehensive automated enumeration difficult. Each handler defines its own structure, meaning slightly malformed data appears as invalid codes rather than exploitable inputs.

The MediaTek Wi-Fi driver source wasn't officially released but appeared in leaked SDKs. Netgear accidentally included the full MediaTek SDK in their GPL-licensed code archives. This gave Hypr C source access while the actual exploitation occurred blind on an ARM-based Netgear router with zero debugging capabilities.

Exploitation Without Instrumentation

Here there is no debugger, no VM and no JTAG pins exposed. Just a Netgear router that kernel-panics and reboots on failed exploitation attempts.

The iteration loop: read kernel source, predict memory layout behavior, send exploit payload, watch for crash or success, reboot the entire device, adjust payload, repeat. Thousands of iterations mapping out heap behavior through stack traces and kernel oops messages that occasionally don't trigger full reboots.

JTAG debugging exists in theory, direct hardware pins for CPU-level kernel debugging, but consumer devices ship with pins unexposed or disabled. Flashing custom kernels to IoT devices risks bricking and requires chip-level hardware manipulation. Hypr chose deterministic reasoning over hardware modification: if computers behave deterministically and the source code is available, controlled experimentation can substitute for instrumentation.

The exploit targets slab allocator free-list metadata. Overflowing 255 bytes beyond chunk boundaries corrupts the next chunk's metadata. If that adjacent chunk is free, its forward pointer (indicating the next free chunk) becomes attacker-controlled. Subsequent allocations return the attacker-specified address, achieving arbitrary write.

modprobe_path: Kernel Write to Shell

Once arbitrary kernel write is achieved, the path to execution goes through modprobe_path, a global kernel variable storing the file path to the modprobe binary. The kernel invokes modprobe when attempting to load drivers for unsupported file formats.

The execution chain:

1. Overwrite modprobe_path string in kernel memory to point at attacker-controlled binary

2. Create a malformed file with invalid magic bytes (not ELF-executable)

3. Attempt to execute the malformed file from user space

4. Kernel detects unsupported format, attempts to load handler via modprobe

5. Kernel executes attacker binary as root

This technique shortcuts the complexity of userland execution from kernel context. Spawning a shell directly from kernel space requires extensive memory mapping and context switching, modprobe_path delegates that work to existing kernel infrastructure.

Pwn2Own: ASLR stuff Pressure

Pwn2Own operates under hard deadlines with unknown target configurations. Hypr's first competition involved joining Sina's team one month before the event to write exploits for bugs Sina had already found.

Both exploits reached ~80% completion but hit ASLR (Address Space Layout Randomization). Without an information leak primitive, the only option was brute force: loop guesses until the address space aligns. In testing, this worked 1-2 times per session. At competition time, you get three attempts.

One exploit missed. The gamble didn't pay off.

Pwn2Own differs from bug bounties: live demonstration on vendor-provided hardware you haven't tested. Memory layout differences between your test environment and the competition device can break exploits. Vendors push patches days before the competition, invalidating months of work. You're not reimbursed for travel costs if your bugs get patched or exploits fail.

The trade-off: massive payouts and significant reputation gains if you succeed. The risk: $10k+ in travel costs with zero return if ASLR doesn't cooperate or a vendor patches 48 hours before demo day.

Real-World Bugs vs CTFs

Bug finding and exploit development are fundamentally different skill sets. CTFs teach exploitation fundamentals in controlled environments with known solutions. Real-world bugs exist in ecosystems filled with defensive mechanisms, environmental constraints, and architectural quirks that determine exploitability.

The delta between "the bug exists" and "the bug is exploitable in this specific environment" is where real expertise develops. POC confirms the vulnerability; exploitation confirms impact.

Working with n-day vulnerabilities (publicly disclosed bugs without patches) provides the ideal midpoint: the bug is known, so you focus purely on exploitation mechanics. Sina's earlier podcast episode showed that debugging setup is essential, but sometimes necessites forces blind exploitation through source code analysis and deterministic reasoning.

Hypr's zero-day workflow involved accumulating 10-15 bugs before attempting exploitation. With multiple primitives available, the question became: "What can I build with these bugs?" Approaching exploitation as creative constraint-solving rather than linear bug to exploit pipelines.

Tooling: Kernel Research Environments

Building kernels is straightforward, but the configuration is complex. Hypr's kernel-utils repo automates stuff like:

• Downloading kernel source matching target versions

• Preset configurations for minimal VM debugging (GDB, KASAN, etc.)

• Debian debootstrap integration for compatible root filesystems

• Iteration support for modifying kernel source and recompiling

IoT driver binaries compiled for ARM don't directly load into x86 VMs. Hypr reverse-engineered the MediaTek driver build process to compile for x86, bypassing the need to emulate ARM or flash modified kernels onto physical devices.

The problem is to emulate a QEMU PCI device that the driver recognizes. The driver loaded without functional Wi-Fi, but that didn't matter, the ioctl attack surface was reachable for verification and testing.

Kernel research is 50% exploitation, 50% build system archaeology. Learning to diagnose compilation failures, chase down legacy toolchains for old kernel versions, and modify source to work in emulated environments is mandatory groundwork.

Lessons on Methodology

Sink-to-source vs source-to-sink: 

Hypr indexes on memory corruption sinks, memcpy calls, size fields without bounds checks. In massive codebases like the Linux kernel, enumerating sources becomes impossible. Find the dangerous pattern first, then trace backward to determine if attacker-controlled data reaches it.

Blind exploitation requires:

• Source code access or exceptional reverse engineering

• Understanding of deterministic system behavior

• Willingness to iterate thousands of times

• Stack traces and kernel oops as substitutes for debugger output

IoT privilege models: 

Most IoT daemons already run as root. Local privilege escalation bugs only matter when:

• The same code runs in non-IoT environments (servers, desktops)

• A remote bug chains through userland services into kernel

• Vulnerability researchers need primitives for Pwn2Own

Resources

• Blog: blog.coffinsec.com - Hypr's technical writeups covering MediaTek vulnerabilities and exploitation techniques

• X: @HyprDude

• ZDI Advisories: Zero Day Initiative regularly publishes n-day vulnerabilities ideal for exploitation practice

• Syzkaller: Linux kernel fuzzing framework with debootstrap scripts for root filesystem generation

That's it for the week, keep hacking!