Pixel 9 0-Click Chain, Part 2: A Codec Bug Reaches the Kernel via /dev/bigwave

Google Project Zero has published Part 2 of a three-part series walking through a complete zero-click exploit chain against a stock Google Pixel 9 — no malicious app, no phishing link, just a message the phone processes on its own. Part 1 covered CVE-2025-54957, an integer-overflow bug in the Dolby Unified Decoder (UDC) that gives an attacker arbitrary code execution inside the mediacodec sandbox simply by getting the device to auto-decode a malicious Dolby Digital Plus audio attachment — the kind of file Google Messages decodes without asking the user anything. Part 2 picks up from that foothold and asks the next question any attacker (or red teamer) would: what can this sandboxed process actually reach?

The answer is /dev/bigwave — a device driver exposing BigWave, hardware on the Pixel SoC that accelerates AV1 video decoding. Researcher Seth Jenkins found it using DriverCartographer, a tool built specifically to enumerate which kernel drivers are reachable from a given SELinux context. AOSP documentation treats mediacodec as a constrained context reserved for untrusted, non-secure decoding work — in practice it still had a direct line to a kernel driver carrying its own attack surface.

A worker thread that outlives its job

The bug tracked as CVE-2025-36934 is a use-after-free rooted in timeout handling. BigWave jobs can time out after roughly 16 seconds; when that happens and the calling process closes the file descriptor, the driver frees the job object (inst) — but the background bigo_worker_thread keeps a reference to it and carries on processing. By spraying kmalloc allocations to reclaim the freed memory and steering register values, Jenkins turned the race into what the post calls "a half decent 2144-byte arbitrary write," enough to pivot from mediacodec to full kernel read/write.

Three separate bugs surfaced in a focused audit of the BigWave driver. One of them wasn't new: it was originally reported in February 2024 and sat unfixed until Jenkins rediscovered it in June 2025, more than a year later. Fixes for all three landed on January 5, 2026.

Why this matters beyond one phone

• A sandbox is defined by everything reachable from inside it, not just the process it contains — a constrained SELinux context is still a launchpad if one reachable driver has a bug.
• Vendor SoC drivers (codec accelerators, ISP, NPU, modem interfaces) rarely get the same scrutiny as the media parsers that trigger them, yet they sit one hop from the kernel.
• A bug reported and left unfixed for over a year is a patch-gap risk in itself — attackers watch disclosed-but-unpatched issues as closely as researchers do.
• Chains like this are why 0-click detection can't stop at the initial codec crash: the more consequential part of the story is everything that happens after.

What to take into a threat model

For teams building or securing Android devices, the practical lesson isn't "patch these three bugs" — they're already fixed. It's that any code reachable from a sandboxed, attacker-influenced context (mediacodec, other constrained SELinux domains, browser renderers) needs its own driver-reachability map, not just a review of the entry point. Project Zero's Part 3 is expected to cover mitigations directly; until then, the DriverCartographer approach — systematically enumerating what an attacker inside your sandbox can actually touch — is reusable well beyond Pixel.