A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens

We recently published an exploit chain for the Google Pixel 9 that demonstrated it was possible to go from a zero-click context to root on Android in just two exploits. The Dolby 0-click vulnerability existed across all of Android, until it was patched in January 2026. While we had an exploit chain for the Pixel 9, we wanted to see if it was possible to write a similar exploit chain for Pixel 10.

Updating the Dolby Exploit

Altering our exploit for CVE-2025-54957 was fairly straightforward. The majority of needed changes involved updating offsets calculated for the specific version of the library we targeted on the Pixel 9 to similar offsets in the library for Pixel 10. The only challenge (outside of wishing we’d better documented which syncframes contained offsets) was that the Pixel 10 uses RET PAC in the place of -fstack-protector, which meant that __stack_chk_fail wasn’t available to be overwritten by code. After a bit of trial and error, we used dap_cpdp_init, initialization code that can be overwritten without causing functional problems, as it is called once when the decoder is initialized and never again. The updated Dolby UDC exploit is available here. This exploit will only work on unpatched devices (SPL December 2025 or earlier).

Removal of BigWave, Addition of VPU

Porting the local privilege escalation link of the chain to Pixel 10 was not feasible as the BigWave driver does not ship on this device. However, a new driver is visible in the mediacodec SELinux context at /dev/vpu. This driver is used for interacting with the Chips&Media Wave677DV silicon on the Tensor G5 chip meant for accelerating video decoding. Based on the comments within the open-source C files, this driver is developed and maintained by the same set of developers who built the BigWave driver. Working in collaboration with Jann Horn, we spent 2 hours auditing this VPU driver and discovered an exceptional vulnerability.

Unlike the upstream Linux driver for WAVE521C (which is an older Chips&Media chip), the Pixel driver for WAVE677DV does not integrate with V4L2 (the “Video for Linux API”); instead, it directly exposes the chip’s hardware interface to userspace, including letting userspace map the chip’s MMIO register interface. The driver mainly establishes device memory mappings, does power management, and allows userspace to wait for interrupts from the chip.

The Holy Grail of Kernel Vulnerabilities

This bug in particular caught our attention as exceptionally simple to exploit:

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;
}

This mmap handler is intended to be used in order to map the MMIO register region of the VPU hardware into the userland virtual address space - a region contained within a certain physical memory address range. In doing so, it makes a call to remap_pfn_range based purely on the size of the VMA and not at all bounded to the size of this register region. This means that, by specifying a size larger than the register region in an mmap syscall, the caller can map as much physical memory as they want into userland, starting at the physical address of the VPU register region. The entirety of the kernel image (including .text, and .data region) is located at a higher physical address than the VPU register region, and can therefore be accessed and modified by userspace with this bug.

At this point, one can simply overwrite any kernel function to gain kernel code execution - or indeed any primitive one might desire. This is rendered even easier by the fact that the kernel is always at the same physical address on Pixel and so the offset between the VPU memory region and the kernel is always a known value. Thus it is not even necessary to scan for the kernel in the mapped physical memory - you simply know exactly where it is relative to the address returned by mmap, presuming you make the VMA length large enough.

Achieving arbitrary read-write on the kernel with this vulnerability required 5 lines of code and writing a full exploit for this issue required less than a day of effort.

Patch Process

I reported this bug on November 24, 2025 and Android VRP rated the issue High severity. This is an improvement, given that the BigWave bug we used for privilege escalation on the Pixel 9 (which had identical security impact) was initially rated as Moderate severity. This represents a meaningful and positive change in posture regarding how these types of bugs are triaged and patched. The vulnerability was patched 71 days after its initial report, in the February Pixel security bulletin. This is notably fast given that this is the first time that an Android driver bug I reported was patched within 90 days of the vendor first learning about the vulnerability.

Conclusion

There are both positives and negatives to take from this research. A key goal of Project Zero is to drive systemic improvements that go beyond individual bug fixes, influencing better development processes and more resilient codebases that lead to improvements in security for end-users. The handling of this VPU vulnerability demonstrates clear progress in Android’s triage pipeline, as this bug had an initial remediation in a much shorter period of time than the previous BigWave issues. Android’s effort to ensure that serious vulnerabilities are patched efficiently will help protect many Android devices.

At the same time, this case underscores the ongoing need for more exhaustively robust and security-aware code in Android drivers. When I reported the bugs in BigWave, I hoped to spur its developers to evaluate their other drivers for obvious security issues, but 5 months later we nevertheless found a serious and extremely shallow vulnerability in their VPU driver that was instantly noticeable with even a cursory audit of the codebase. Strengthening driver security remains a crucial priority for ensuring a safe Android ecosystem, and we continue to strongly encourage vendors to improve software development practices in a proactive effort to prevent these sorts of vulnerabilities from ever reaching end-users.

Security reports often uncover complex issues missed by the product teams but it is important that software vendors take necessary steps to ensure software products, especially security-critical ones, launch in a reasonably vulnerability-free state and that software teams take a proactive approach to software security, code auditing, and vulnerability patching.