GBHackers

Google Project Zero Details Pixel 10 Zero-Click Exploit Chain


A powerful zero-click exploit chain for the Pixel 10 that can take an attacker from a remote Dolby decoding bug to full kernel control through a single vulnerable video processing driver.

The work shows both how quickly Google can now patch critical issues and how shallow mistakes in vendor drivers can still undermine Android’s security model.

Pixel 10 Zero-Click Exploit Chain

The chain’s entry point is the same Dolby Unified Decoder vulnerability, CVE-2025-54957, that previously impacted Pixel 9 and other Android devices.

The bug, now patched in the January 2026 Android update, allowed remote code execution when a crafted Dolby Digital Plus (DD+) audio stream was processed, turning audio attachments and voice messages into a zero-click attack surface.

For Pixel 10, Project Zero’s Seth Jenkins updated their existing exploit by recalculating offsets for the new Dolby library build. The main complication came from the switch to return address pointer authentication (RET PAC) instead of the classic stack-protector, which removed the previous __stack_chk_fail overwrite primitive.

To regain code execution, the team instead targeted dap_cpdp_init, an initialization function that runs once, can be safely overwritten, and doesn’t impact normal decoding once the process completes. The updated Dolby UDC exploit works only on devices that have not yet received the December 2025/January 2026 patches.

On Pixel 9, the second stage relied on a BigWave AV1 driver bug to escalate local privileges to the kernel. The Pixel 10 no longer ships with the BigWave driver.

However, it introduces a new /dev/vpu driver that interfaces with the Chips&Media Wave677DV block on the Tensor G5 for hardware video decoding. The same developer team behind BigWave also maintains this VPU driver, making it a natural target for a quick audit.

In just two hours of review, Jenkins and Jann Horn uncovered a critical vulnerability in the VPU mmap handler that effectively exposes arbitrary physical memory to user space.

The core of the problem is a minimal vpu_mmap implementation that maps a physical region starting at the VPU registers into a user-provided virtual memory area, but never checks that the requested size stays within the VPU MMIO range. The vulnerable code looks like this:

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;
    return remap_pfn_range(vm, vm->vm_start, pfn,
                           vm->vm_end - vm->vm_start,
                           vm->vm_page_prot) ? -EAGAIN : 0;
}

Because the call to remap_pfn_range uses only the VMA length, a caller can pass an oversized mapping and extend far beyond the VPU registers, pulling in arbitrary physical memory, including the entire kernel image.

On Pixel, the kernel is always at a fixed physical address. Hence, attackers know exactly where to read and write relative to the base VPU region without any KASLR-bruteforcing or scanning.

Project Zero reports that building an arbitrary kernel read-write primitive took just five lines of code, and a full exploit was completed in under a day.

Jenkins reported the VPU bug on November 24, 2025, and Android’s VRP classified it as High severity, an improvement over a similar BigWave issue that was initially rated Moderate despite identical impact.

Google shipped a fix 71 days later in the February Pixel security bulletin, marking the first time one of Jenkins’ reported Android driver bugs was patched in under 90 days.

The case underscores two parallel trends: Android’s triage and patching pipeline for serious driver bugs is clearly improving, but shallow, easily discoverable vulnerabilities remain in vendor-maintained kernel code.

Project Zero stresses that systematic secure coding, proactive driver audits, and stronger development practices are still essential if OEMs want to stop these zero-click chains before they ever reach users.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.



Source link