The Pixel 10 0-Click Chain: A Case Study in Driver Vulnerabilities

The security of modern smartphones often feels like a game of cat and mouse. When one door is closed via a patch, researchers often find a window left open. This is precisely what happened with the recent research from Google Project Zero, which successfully developed a 0-click exploit chain for the Pixel 10.

By evolving a previous exploit used on the Pixel 9 and discovering a critical flaw in a new hardware driver, the team demonstrated how a remote attacker could move from a zero-click context to full root access on the device. This case study provides a stark reminder of the fragility of the Android driver ecosystem and the systemic challenges of securing hardware-accelerated components.

The First Link: Updating the Dolby Exploit

The journey to root began with an existing vulnerability in the Dolby decoder (CVE-2025-54957). While this vulnerability was patched in January 2026, Project Zero sought to determine if their previous Pixel 9 exploit could be ported to the Pixel 10.

Updating the exploit was relatively straightforward, primarily requiring the adjustment of memory offsets to match the Pixel 10's library versions. However, the team encountered a new hurdle: the Pixel 10 utilizes RET PAC (Pointer Authentication Code) instead of the traditional -fstack-protector. This meant that the common target for overwriting, __stack_chk_fail, was no longer available. To bypass this, the researchers identified dap_cpdp_init—initialization code that is called only once during decoder initialization—as a viable target for overwriting without destabilizing the system.

The Second Link: From Userland to Kernel

While the Pixel 9 exploit relied on the "BigWave" driver for local privilege escalation (LPE), the Pixel 10 does not ship with that driver. Instead, the researchers identified a new driver at /dev/vpu, used for interacting with the Chips&Media Wave677DV silicon on the Tensor G5 chip for video decoding acceleration.

Upon auditing the VPU driver, Project Zero discovered a vulnerability that they described as the "Holy Grail of Kernel Vulnerabilities." The flaw resided in the vpu_mmap handler:

static int vpu_mmap(struct file *fp, struct vm_area_struct *vm)
{
    unsigned long pfn;
    struct vpu_core *core = 
        container_of(fp->f_inode->i_cdev, struct vpu_core, cdev);

    vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP);
    /* This is a CSRs mapping, use pgprot_device */
    vm->vm_page_prot = pgprot_device(vm->vm_page_prot);
    pfn = core->paddr >> PAGE_SHIFT;

    return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0;
}

The Mechanics of the Flaw

The vpu_mmap function is intended to map the MMIO (Memory-Mapped I/O) register region of the VPU hardware into the userland virtual address space. However, the implementation fails to bound the size of the mapping to the actual size of the register region. By specifying a size larger than the register region in an mmap syscall, a caller can map an arbitrary amount of physical memory into userland, starting from the VPU register region.

Because the Android kernel on Pixel devices is located at a fixed physical address, the offset between the VPU memory region and the kernel is constant. This allows an attacker to simply map a large enough region of memory to encompass the kernel image, granting them arbitrary read-write access to the kernel's .text and .data regions.

Project Zero noted that achieving arbitrary read-write access required only five lines of code, and a full exploit took less than a day to develop.

Triage, Patching, and Systemic Failures

Project Zero reported the bug on November 24, 2025. In a positive shift, Android's Vulnerability Reward Program (VRP) rated the issue as High severity, and a patch was deployed within 71 days. This is significantly faster than previous remediations for similar driver bugs.

Despite the improved triage speed, the research highlights a systemic issue. The VPU driver was developed by the same team that created the flawed BigWave driver. Despite the previous high-profile vulnerabilities in BigWave, the VPU driver launched with a "shallow" vulnerability that was instantly noticeable during a cursory audit.

Community Perspectives and Broader Implications

The disclosure of this exploit has sparked significant discussion among the security community regarding the role of AI and the state of hardware drivers.

AI as a Security Tool

Some researchers noted that modern LLMs are becoming surprisingly capable of identifying such vulnerabilities. One commenter mentioned that a prompt containing the vpu_mmap function was correctly identified as vulnerable by an AI model without any external web search, raising questions about whether AI will accelerate the discovery of exploits or the remediation of bugs.

The "Black Box" of BSPs

There is a recurring concern regarding Board Support Packages (BSPs). While the Pixel's BSP is relatively open, many other Android devices use proprietary, closed-source drivers. As one commenter noted:

"Imagine the dark horrors hiding in the BSPs of other Android devices... or embedded devices in general. Frankly, it should be a requirement of Google's certification process that everything regarding drivers gets upstreamed into the Linux kernel."

The Trade-off of Features vs. Security

Finally, the research touches on the tension between user-facing features and security. The increase in 0-click attack surfaces is often driven by the need to decode media for AI-powered features (like message summaries) before a user even opens a message. This creates a paradox where the very features designed to improve user experience inadvertently open new vectors for remote exploitation.