The Pixel 10 Zero-Click Exploit Chain: From Audio Decoding to Kernel Control

In the high-stakes landscape of mobile security, a single oversight in a vendor-supplied driver can bypass even the most sophisticated hardware protections.

A recent research discovery has demonstrated a sophisticated zero-click exploit chain targeting the Google Pixel 10. This chain demonstrates a terrifyingly efficient path: moving from a remote, unauthenticated audio decoding bug to full, unrestricted kernel-level privileges through a single vulnerable video processing driver.

This discovery highlights a dual reality in modern mobile security: while Google’s ability to triage and deploy critical security patches is accelerating, the “shallow” mistakes found in third-party vendor drivers continue to pose a significant threat to the integrity of the Android security model.

The Entry Point: Leveraging the Dolby Unified Decoder

The exploit chain begins with a vulnerability in the Dolby Unified Decoder, identified as CVE-2025-54957. This is a legacy issue that previously impacted the Pixel 9 and various other Android-based devices. The vulnerability allows for Remote Code Execution (RCE) when the system attempts to process a maliciously crafted Dolby Digital Plus (DD+) audio stream. Because audio processing often happens automatically when a user receives a message, this turns seemingly benign assets—like voice messages or audio attachments—into a potent zero-click attack vector.

As Project Zero’s Seth Jenkins documented, adapting this exploit for the Pixel 10 required significant engineering. The transition to the new hardware architecture necessitated a complete recalculation of memory offsets for the updated Dolby library. Furthermore, researchers encountered a new hurdle: the Pixel 10 utilizes Return Address Pointer Authentication (RET PAC) rather than the traditional stack-protector. This mitigation effectively neutralized the previous __stack_chk_fail overwrite primitive used in earlier versions.

To bypass this, the research team pivoted their strategy. Instead of fighting the stack protector, they targeted dap_cpdp_init—an initialization function. Because this function runs only once during startup and its state can be safely manipulated without crashing the ongoing decoding process, it provided a reliable way to regain code execution. It is important to note that this specific UDC exploit remains viable only on devices that have not yet applied the December 2025 or January 2026 security patches.

Privilege Escalation: The VPU Driver Vulnerability

On previous hardware like the Pixel 9, attackers relied on a bug in the BigWave AV1 driver to escalate privileges to the kernel. However, the Pixel 10 architecture has moved away from the BigWave driver, introducing a new /dev/vpu driver instead. This driver interfaces with the Chips&Media Wave677DV block on the Tensor G5 chip for hardware-accelerated video decoding.

In a striking display of how quickly vulnerabilities can surface in new code, Jenkins and Jann Horn identified a critical flaw in the VPU’s mmap handler after only two hours of auditing. The vulnerability lies in the implementation of vpu_mmap, which fails to validate the bounds of the memory being mapped.

The vulnerable C code responsible for this is shown below:

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);
    vm->vm_page_prot = pgprot_device(vm->vm_page_prot);
    pfn = core->paddr >> PAGE_SHIFT;
    /* The flaw: No check to ensure (vm->vm_end - vm->vm_start) 
       stays within the intended VPU MMIO range */
    return remap_pfn_range(vm, vm->vm_start, pfn,
                           vm->vm_end - vm->vm_start,
                           vm->vm_page_prot) ? -EAGAIN : 0;
}

The logic error is fundamental: the remap_pfn_range function uses the user-provided Virtual Memory Area (VMA) length without verifying that it stays within the VPU’s Memory-Mapped I/O (MMIO) range. By passing an oversized mapping request, an attacker can “stretch” the mapping far beyond the VPU registers, effectively mapping arbitrary physical memory into user space. This includes the kernel image itself.

Because the Android kernel resides at a predictable physical address on Pixel devices, the attacker can bypass Kernel Address Space Layout Randomization (KASLR) without needing complex memory scanning or brute-forcing. According to Project Zero, constructing an arbitrary kernel read-write primitive required only five lines of code, allowing a functional exploit to be finalized in less than 24 hours.

A Race Between Triage and Technical Debt

The lifecycle of this bug highlights an encouraging trend in Google’s response. Jenkins reported the VPU vulnerability on November 24, 2025, and the Android Vulnerability Rewards Program (VRP) correctly classified it as “High” severity. Google subsequently delivered a patch in the February security bulletin—a turnaround of just 71 days. This is a notable improvement over previous instances where similar driver bugs were initially misclassified or took much longer to remediate.

However, the existence of such a “shallow” bug in a critical video driver serves as a sobering reminder. As long as OEMs rely on vendor-maintained drivers that lack rigorous, systematic security audits, the attack surface for zero-click chains will remain wide. To truly harden the Android ecosystem, the industry must move beyond reactive patching and toward proactive, secure coding standards and deep architectural audits of third-party kernel components.