A door closes, a window opens: Project Zero's 0-click chain reaches the Pixel 10 kernel

An SMS lands. Your phone buzzes. You don't tap it — you don't even unlock the screen. By the time you glance at the notification, an attacker is already reading and writing your kernel memory.

That's the shape of a 0-click exploit, and over a multi-part series Google's own Project Zero has now walked one from a Pixel 9 all the way onto the Pixel 10 — patching a "door" only to find the vendor had left a wider "window" open right beside it. Here's what actually happens in the chain, why the kernel is the real prize, and why the Pixel 10 variant is simpler than the one before it.

The front door: a media codec you never asked to run#

The entry point isn't an app you installed or a link you clicked. Google Messages automatically decodes inbound audio attachments over SMS/RCS — the feature that lets the app handle a voice note before you ever open it. No interaction required. That auto-decode quietly routes attacker-controlled audio into Android's media codecs, and one of those codecs is Dolby's UDC decoder.

CVE-2025-54957 is an integer overflow in how the Dolby UDC decoder sizes an EMDF payload allocation. On 64-bit Android, when the total_size value is padded to an 8-byte boundary, the arithmetic can overflow — and the decoder then allocates a buffer smaller than the data it's about to write. The result is a controllable heap overrun (under ~3,066 bytes per frame) plus an information leak, because an oversized emdf_container_length lets the attacker read past the intended boundary. One malformed audio frame, delivered by text, and the attacker has both a write primitive and a leak inside the media process.

Project Zero's Seth Jenkins chains that into arbitrary kernel read/write from user space using /proc/self/mem writes and ROP built on manipulated GOT pointers — the plumbing that turns a bounded heap bug into a general-purpose weapon before the exploit even reaches the kernel.

The door (Pixel 9): a race in BigWave#

To break out of the sandbox on the Pixel 9, the chain abused the BigWave video driver. CVE-2025-36934 is a use-after-free there: when a BIGO_IOCX_PROCESS ioctl times out — after a full 16 seconds — while the bigo_worker_thread is still processing the same job, the job struct gets freed out from under the worker. Reclaim that freed slot with attacker-controlled data and you own the write:

"By spraying attacker-controlled kmalloc allocations (for example via Unix Domain Socket messages) we can control the underlying UAF pointer job->regs, so we can control the destination of our write." — Seth Jenkins

The payoff is a 2,144-byte arbitrary kernel write. That's enormous — and messy: the same over-broad write that makes the exploit powerful also caused spurious crashes elsewhere in the system (toggling Wi-Fi was a notable casualty). Google fixed the Pixel 9 chain on January 5, 2026, before Project Zero published.

The window (Pixel 10): the VPU driver hands you the kernel#

Here's where "a door closes, a window opens" earns its name. On the Pixel 10, BigWave is gone. In its place sits a new video-processing-unit (VPU) driver — and it contains a far cruder bug.

The vpu_mmap handler calls remap_pfn_range without bounding the size parameter the caller supplies. Translation: user space can ask the driver to map memory starting at the VPU register region and just… keep going. And because of where that region sits in physical memory, "keep going" runs straight into the kernel itself.

"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." — Seth Jenkins

No race to win. No 16-second timeout to thread. No giant, crash-prone spray. Where the Pixel 9's BigWave bug needed careful heap grooming and still guessed two ASLR nibbles (a 1-in-16 shot each, dragging the average successful run to about six minutes), the Pixel 10's VPU bug needs no info leak at all — the MMIO offset is fixed. Map the memory, read and write the kernel. The newer, "harder" phone gave the attacker a shorter path.

The Dolby front door survived the generation too: the same CVE-2025-54957 works on the Pixel 10 with adjusted offsets. Because RET pointer authentication (PAC) is now in play, the exploit overwrites the dap_cpdp_init function pointer instead of the old __stack_chk_fail target — a small detour, same result.

Google rated the VPU bug High severity. It was reported on November 24, 2025 and patched in February 2026 — a 71-day turnaround.

Why the kernel is the prize#

A bug in a media codec is contained by the sandbox around that process. A bug in the kernel is not — and that's why this chain matters beyond one handset. As Jenkins notes, a kernel vulnerability tends to be identical across every Android device that ships the affected driver, and Android's patch pipeline is slow by construction: a fix lands in the upstream LTS Linux kernel, then has to flow into the Android common kernel, then into each vendor's device kernel, then out to users. Each hop adds latency, and the gaps can stretch into years. A framework bug is a broken lock on one door; a kernel bug is a master key with a long, slow recall.

Reality check#

Before anyone throws their Pixel in a drawer: both chains are Project Zero proofs-of-concept, published after the fixes shipped, and there's no evidence of in-the-wild exploitation. The Pixel 9 chain was also genuinely fiddly — it needed three MP4 files stuffed into a single message to groom the heap into the right state, tolerated random crashes, and leaned on quirks of Android's scudo allocator that don't obviously generalize. This is elite, patient offensive research, not a point-and-click kit.

But that's the point of publishing it. The takeaway isn't "Pixels are broken." It's that adding attack surface — a brand-new VPU driver on a newer, ostensibly more hardened phone — can hand attackers an easier path than the one you just closed. Mitigations like PAC raise the cost at the edges; an unbounded remap_pfn_range in a fresh driver erases all of it. Keep automatic updates on, take the monthly security patch the day it lands, and — if you write drivers — bound your mmap sizes.