A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens
Project Zero builds a 0-click exploit chain to root on the Pixel 10 after the earlier Dolby bug was fixed.
Extract
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 …
Explained
What happened
Google Project Zero had already shown a two-bug chain on the Pixel 9: a zero-click bug in the Dolby audio decoder, then a kernel driver bug to get root. They checked whether the same approach worked on the Pixel 10.
- The first step carried over. The Dolby decoder bug (
CVE-2025-54957, fixed in the January 2026 bulletin) still applied to Pixel 10 builds before the fix. - The old kernel driver was gone, but a new video driver for the Tensor G5's hardware video decoder was reachable from the same media sandbox.
- The new driver had a serious bug. Its
mmaphandler maps the decoder's hardware register region into user space, but it sized the mapping from the caller's request instead of the real size of that region. A caller could map far more physical memory than intended, including memory that holds the kernel. - Easy to find, easy to abuse. Two researchers found it in about two hours of review. Because the kernel sits at a fixed physical address on these devices, getting full kernel read and write took very little code.
- The response was faster this time. The bug was reported on November 24, 2025, rated High, and fixed 71 days later in the February Pixel bulletin. The author says it was the first Android driver bug they reported that was fixed within 90 days. The Pixel 9 driver bug with the same impact had first been rated Moderate.
Why it works
The root cause is a missing bounds check at a trust boundary. Driver code that maps hardware into a process is very powerful: it hands user space a direct window onto physical memory. Unlike the upstream Linux driver for an older chip from the same vendor, this one skipped the standard Video4Linux layer and exposed the hardware interface almost directly. That leaves very little code between an untrusted process and physical memory.
The media sandbox does not help much if a driver reachable from inside it has a bug like this. Hardening such as pointer authentication made the first step a bit harder, but did not stop the chain.
The bigger pattern
This is the familiar attack surface problem with vendor drivers. Each new chip brings a new custom driver, often from the same team, and the same class of bug comes back. A 0-click media bug plus one driver bug is enough, because media parsing runs on untrusted input without any user action.
The positive part is process: faster triage and a higher severity rating than before show real progress in how these bugs are handled.
What it means in practice
- Any code that maps memory or hardware for a less trusted caller must check the requested size and offset against what it actually owns. Review such code with extra care.
- Prefer well-reviewed shared frameworks over custom interfaces that expose hardware directly.
- Process untrusted media (uploads, thumbnails, transcodes) in tightly sandboxed workers with minimal device and syscall access, and keep codec libraries patched.
- Fixed memory layouts make exploits easier; keep randomization features enabled where your platform supports them.
- Track time-to-patch for your own dependencies, not just whether a fix exists.