Pixel 9 BigWave Driver: Sandbox Escape Analysis & Hardening Guide

Google Project Zero researchers have disclosed a critical security issue chain affecting the Pixel 9 series, specifically detailing a sandbox escape mechanism leveraging the "BigWave" hardware driver. While Part 1 of the series focused on a code execution flaw in the Dolby Unified Decoder, Part 2 reveals how an attacker can leverage the resulting mediacodec context to escape the Android sandbox and interact with the kernel via the /dev/bigwave device node.

For defenders, this highlights a critical failure in the principle of least privilege. The mediacodec SELinux context is designed to constrain non-secure software decoders, yet it was granted unnecessary access to a hardware-accelerated AV1 decoder driver. This bridge allows attackers to transition from a userland codec process to potential kernel-level code execution. Organizations with Pixel fleets must treat this with high urgency due to the 0-click nature of the initial exploit chain.

Technical Analysis

Affected Products & Platforms:

• Hardware: Google Pixel 9 series (Tensor chipsets).
• Software: Android OS versions utilizing the vulnerable kernel driver and SELinux policy.

Vulnerability Mechanics: The attack chain involves two distinct stages:

1. Initial Entry: Exploitation of the Dolby Unified Decoder (RCE) within the mediacodec service.
2. Sandbox Escape: The mediacodec context holds permissions to interact with /dev/bigwave, a driver for the BigWave hardware (AV1 accelerator).

Typically, mediacodec is a sandboxed environment. However, Google Project Zero's DriverCartographer tool revealed that this context could reach /dev/bigwave. The BigWave kernel driver, like many hardware drivers in the Android ecosystem, likely lacks sufficient input validation or strict context checks when handling IOCTLs (Input/Output Controls) from userland. By crafting malicious inputs to the Dolby decoder, an attacker gains code execution in mediacodec, then issues commands to /dev/bigwave to trigger a kernel vulnerability, effectively breaking out of the sandbox.

Exploitation Status:

• Proof of Concept (PoC): Available / Public.
• In-the-Wild: Not explicitly confirmed in the wild at the time of writing, but the technical details provide a roadmap for advanced threat actors.

Detection & Response

Detecting 0-click exploits on mobile endpoints is notoriously difficult. Standard EDR may not capture the specific interaction with /dev/bigwave unless kernel auditing is enabled. However, we can detect the post-exploitation behavior: a media codec process spawning an unauthorized shell or interacting with the debugging bridge (adb).

Sigma Rules

---
title: Pixel BigWave - Suspicious Shell Spawn from MediaCodec
id: 550d9a23-0f72-4e3a-a8c5-1d2f3b4c5d6e
status: experimental
description: Detects when the Android MediaCodec process (mediacodec) spawns a shell (sh/bash), indicating a potential sandbox escape or code execution.
references:
  - https://projectzero.google/2026/01/pixel-0-click-part-2.html
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  product: android
  category: process_creation
detection:
  selection:
    ParentImage|contains: 'mediatek' # or specific vendor media path
    Image|endswith:
      - '/sh'
      - '/bash'
  condition: selection
falsepositives:
  - Legitimate developer debugging (rare in production)
level: high
---
title: Pixel BigWave - ADB Activity by Media Context
id: 7a3f1c82-9e4b-4d67-bc12-3e5a8f901234
status: experimental
description: Detects attempts to enable or interact with ADB (Android Debug Bridge) spawned from a media codec context.
references:
  - https://projectzero.google/2026/01/pixel-0-click-part-2.html
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t1059
logsource:
  product: android
  category: process_creation
detection:
  selection:
    ParentImage|contains: 'codec'
    Image|contains: 'adb'
  condition: selection
falsepositives:
  - Authorized testing via USB debugging
level: critical

KQL (Microsoft Sentinel)

Assuming ingestion of Android logs via Microsoft Defender for Endpoint or MDM connectors into DeviceProcessEvents.

// Hunt for suspicious process spawns from media codec contexts
DeviceProcessEvents
| where InitiatingProcessFolderPath contains "codec" 
   or InitiatingProcessFileName contains "mediacodec"
| where ProcessVersionInfoOriginalFileName in~ ("sh", "bash", "adb", "nc", "netcat")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

Velociraptor VQL

Use this artifact to hunt for unexpected parent-child relationships on rooted or monitored devices where Velociraptor is deployed.

-- Hunt for media codec processes spawning shells
SELECT Parent.Pid AS ParentPid, Parent.Name AS ParentName,
       Pid, Name, Exe, CommandLine, StartTime
FROM pslist()
LEFT JOIN pslist() AS Parent ON Parent.Pid = Ppid
WHERE Name =~ '(sh|bash|adb)'
  AND Parent.Name =~ 'mediacodec'

Remediation Script (Bash)

This script checks for the presence of the /dev/bigwave driver and verifies the Android security patch level against the expected fix date.

#!/bin/bash

# Pixel 9 BigWave Vulnerability Check
# Checks for /dev/bigwave and verifies patch level

echo "[+] Checking Pixel 9 BigWave Exposure..."

# Check if the device node exists (likely present on hardware)
if [ -e "/dev/bigwave" ]; then
    echo "[!] WARNING: /dev/bigwave is accessible."
else
    echo "[+] /dev/bigwave not found."
fi

# Check Security Patch Level
PATCH_DATE=$(getprop ro.build.version.security_patch)
echo "[+] Current Security Patch: $PATCH_DATE"

# Convert to epoch for comparison (Simplified logic for YYYY-MM)
# Expected fix is typically in the month following disclosure or next OTA
TARGET_FIX="2026-02-01"

if [[ "$PATCH_DATE" < "$TARGET_FIX" ]]; then
    echo "[!] CRITICAL: Device is vulnerable. Patch level is prior to $TARGET_FIX."
    echo "[!] ACTION REQUIRED: Apply latest Android Security Update immediately."
else
    echo "[+] Device appears patched against this specific issue."
fi

Remediation & Hardening

1. Patch Immediately: The primary remediation is applying the Android Security Update containing the fix for the BigWave driver interaction. Verify that the patch date on the device is February 2026 or later.
2. Verify SELinux Policy: Ensure the device is in Enforcing mode. The vulnerability relies on an overly permissive SELinux policy allowing mediacodec access to bigwave. Google will likely update the policy to neverallow this interaction in future releases.
3. Restrict Untrusted Media: Until patches are deployed, advise high-risk users to avoid processing untrusted media files (malicious MMS, web pages) from unknown sources, although this is difficult to enforce in a 0-click scenario.

Vendor Advisory: Google Android Security Bulletin (February 2026).

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub