Attacking NPUs of Multiple Platforms
This talk demonstrates multiple memory corruption vulnerabilities, including use-after-free and integer overflows, within the NPU drivers and firmware of Samsung Exynos and Apple Neural Engine platforms. The researchers detail how these vulnerabilities arise from improper handling of shared DMA buffers and race conditions between user-space and kernel-space. The presentation provides a practical methodology for exploiting these flaws to achieve arbitrary code execution and root privileges on mobile devices. The researchers also introduce the 'dirty-pagetable' technique for exploiting use-after-free vulnerabilities in the Linux kernel.
Rooting Mobile Devices via NPU Driver Vulnerabilities
TLDR: Modern mobile devices offload AI tasks to Neural Processing Units (NPUs), but these specialized drivers are often riddled with memory corruption bugs. Researchers recently demonstrated how to exploit use-after-free and integer overflow vulnerabilities in Samsung Exynos and Apple Neural Engine drivers to gain root privileges. Pentesters should prioritize auditing these proprietary drivers, as they frequently lack modern OS-level mitigations and provide a direct path to kernel-space execution.
Neural Processing Units (NPUs) are now standard in flagship mobile chipsets, handling everything from facial recognition to real-time image processing. While developers focus on securing the application layer, the hardware-accelerated drivers powering these AI features have become a massive, largely unexamined attack surface. Recent research presented at Black Hat 2023 highlights that these drivers are often written with minimal security oversight, lacking basic memory protections that have been standard in the Linux kernel for years.
The Anatomy of NPU Driver Exploitation
The core issue across these platforms is the flawed management of shared memory between user-space and the NPU firmware. Drivers typically allocate DMA buffers to facilitate communication, but the synchronization logic between the kernel-space driver and the NPU firmware is frequently broken.
In the case of the Samsung Exynos NPU, the driver uses a mailbox mechanism to queue requests. The researchers identified that the driver fails to properly validate the state of these buffers, leading to race conditions. Specifically, CVE-2023-42483 demonstrates a classic time-of-check to time-of-use (TOCTOU) vulnerability. Because the driver and the firmware share the same DMA buffer, a malicious user-space application can modify the buffer contents after the kernel has validated the request parameters but before the firmware processes them.
This pattern is not unique to Samsung. The Apple Neural Engine (ANE) suffers from similar architectural weaknesses. The researchers found that the H11ANEInterface kernel extension was vulnerable to type confusion and out-of-bounds access due to improper validation of input structures. By manipulating the mutable sections of the model file, an attacker can trigger an out-of-bounds write, leading to arbitrary code execution.
Exploiting the Linux Kernel with Dirty Pagetable
One of the most significant takeaways from this research is the introduction of the "dirty-pagetable" technique. When dealing with use-after-free (UAF) vulnerabilities in the Linux kernel, traditional heap grooming often fails due to modern slab allocators. The researchers bypassed these protections by targeting the page tables themselves.
By forcing the kernel to allocate a page table in a memory region previously occupied by a freed object, an attacker can gain read/write access to arbitrary physical memory. This is a powerful primitive. During their demo on a Samsung S20 5G, the team used this technique to bypass SELinux and spawn a root shell. The exploit relies on the fact that the NPU driver's memory management is decoupled from the main kernel's memory protections, allowing the attacker to manipulate kernel structures without triggering a system panic.
If you are performing a mobile security assessment, stop focusing solely on the application's API endpoints. Start looking at the ioctl interfaces exposed by these hardware drivers. You can list the available devices on an Android handset using adb:
ls -l /dev/
Look for entries like /dev/msm_npu or /dev/vertex10. These are your entry points. Use Ghidra to reverse the ioctl handlers. If you see a pattern where the driver copies a structure from user-space, validates it, and then processes it without holding a lock or using a private copy, you have found a potential TOCTOU or double-fetch vulnerability.
The Defensive Reality
Defenders are currently fighting a losing battle with NPU drivers. These components are often sourced from third-party vendors and integrated into the kernel with little to no hardening. The lack of modern OS mitigations like Kernel Address Space Layout Randomization (KASLR) or Control Flow Integrity (CFI) within these drivers makes them an ideal target for exploit developers.
For blue teams, the best approach is to restrict access to these device nodes via SELinux policies. If an application does not strictly require NPU acceleration, it should be explicitly denied access to the corresponding /dev/ nodes. However, this is a stopgap. The real solution requires hardware vendors to treat NPU drivers with the same rigor as the core kernel, implementing strict input validation and ensuring that all shared memory operations are atomic.
What Comes Next
The research into NPU vulnerabilities is still in its infancy. While the team focused on Samsung and Apple, the same architectural flaws are likely present in other mobile chipsets. The "dirty-pagetable" technique is a reminder that as we harden the heap, attackers will simply move down the stack to the page tables.
If you are hunting for bugs in this space, look for the "double-fetch" pattern. Any time a driver fetches a value from a shared buffer twice—once for validation and once for use—you have a potential exploit. The NPU is the new frontier for mobile exploitation, and the current state of these drivers suggests that we are only seeing the tip of the iceberg. Investigate the ioctl handlers, map out the shared memory structures, and start looking for the race conditions that the vendors missed.
CVEs
Vulnerability Classes
Target Technologies
OWASP Categories
All Tags
Up Next From This Conference

A Security RISC? The State of Microarchitectural Attacks on RISC-V

REDIScovering HeadCrab: A Technical Analysis of a Novel Malware and the Mind Behind It

TsuKing: Coordinating DNS Resolvers and Queries into Potent DDoS Amplifiers
Similar Talks

Inside the FBI's Secret Encrypted Phone Company 'Anom'

Hacking Apple's USB-C Port Controller

