Pixel BigWave BIGO timeout race UAF → mediacodec からの 2KB カーネル書き込み
Tip
AWSハッキングを学び、実践する:
HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
Azureハッキングを学び、実践する:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricksをサポートする
- サブスクリプションプランを確認してください!
- **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
- HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。
TL;DR
- From the SELinux-confined mediacodec context,
/dev/bigwave(Pixel AV1 hardware accelerator) is reachable. A backlog of jobs makesBIGO_IOCX_PROCESShit its 16s wait_for_completion_timeout() and return while the worker thread concurrently dequeues the same inlinejobstructure. - Closing the FD immediately frees
struct bigo_inst(which embedsstruct bigo_job). The worker reconstructsinst = container_of(job, ...)and later uses freed fields such asjob->regsinsidebigo_run_job(), yielding a Use-After-Free on the inline job/inst. bigo_pull_regs(core, job->regs)performsmemcpy_fromio(regs, core->base, core->regs_size). By reclaiming the freed slab and overwritingjob->regs, an attacker gets a ~2144-byte arbitrary kernel write to a chosen address, with partial control of the bytes by pre-programming register values before the timeout.- Tracked as CVE-2025-36934; fixed in the 2026-01-05 Pixel/2025-12-01 ASB builds.
Attack surface mapping (SELinux → /dev reachability)
- Use tools like DriverCartographer to enumerate device nodes accessible from a given SELinux domain. Despite mediacodec’s constrained policy (software decoders should stay in an isolated context),
/dev/bigwaveremained reachable, exposing a large attack surface to post-media-RCE code.
Vulnerability: BIGO_IOCX_PROCESS timeout vs worker
- Flow: ioctl copies user register buffer into
job->regs, queues the inlinejob, thenwait_for_completion_timeout(..., 16s)is called. On timeout it tries to dequeue/cancel and returns to userspace. - Meanwhile
bigo_worker_threadmay have just dequeued the samejob:
inst = container_of(job, struct bigo_inst, job);
bigo_push_regs(core, job->regs);
...
bigo_pull_regs(core, job->regs); // memcpy_fromio(regs, core->base, core->regs_size)
*(u32 *)(job->regs + BIGO_REG_STAT) = status;
- If userspace closes the FD after the timeout,
inst/jobare freed while the worker keeps using them → UAF. No synchronization ties FD lifetime to the worker thread’s job pointer.
エクスプロイトの概要
- Backlog + timeout: worker が遅延するように十分なジョブをキューイングし、
BIGO_IOCX_PROCESSを実行して 16 秒の timeout パスに到達させる。 - Free while in use: ioctl が戻ったら直ちに
close(fd)を呼んで、worker がまだデキューしたジョブを実行している間にinst/jobを解放する。 - Reclaim + pointer control: 解除された slab スロットを占有してインライン
job(特にjob->regs)を上書きするために、reclaimer をスプレーする(例: Unix domain socket message の割り当て)。 - Arbitrary write:
bigo_pull_regs()実行時にmemcpy_fromio()は MMIO から core->regs_size (~2144 bytes) をjob->regsにある攻撃者指定のアドレスへ書き込み、KASLR leak なしで大規模な write-what-where を生み出す。 - Data shaping: レジスタはまずユーザデータ(
bigo_push_regs)からプログラムされるため、ハードウェアが実行しないように設定し、コピーされたレジスタ画像が攻撃者制御下のバイトに近い状態を維持する。
最小 PoC スケルトン (blocking backlog + reclaim)
int fd = open("/dev/bigwave", O_RDWR);
for (int i = 0; i < 64; i++) submit_job(fd, regs_buf); // fill worker queue
submit_job(fd, regs_buf); // victim job
auto t0 = now();
while (now() - t0 < 17000ms) sched_yield(); // hit 16s timeout
close(fd); // free inst/job
spray_uds_msgs(payload_pointing_to_target, spray_count); // reclaim slab
sleep(1); // let worker memcpy_fromio
regs_bufは、コピーバックされたレジスタイメージが決定論的に保たれるように、BigWave をアイドル状態に事前設定するべきです(例:実行をスキップするために制御ビットを設定する)。
ドライバレビュワー向け要点
- async workers にエンキューされる inline の per-FD job 構造体は、timeout/cancel 経路を通過しても参照を保持し続ける必要がある;FD を閉じる操作はワーカーの消費と同期する必要がある。
- ジョブ由来のバッファポインタを使用する MMIO コピーヘルパー(
memcpy_fromio/memcpy_toio)は、エンキューする前に検証するか複製して、UAF→write primitives を回避するべきである。
参考資料
- Pixel 0-click (Part 2): Escaping the mediacodec sandbox via the BigWave driver
- Project Zero issue 426567975 – BigWave BIGO timeout UAF
- CVE-2025-36934 entry (BigWave driver)
Tip
AWSハッキングを学び、実践する:
HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
Azureハッキングを学び、実践する:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricksをサポートする
- サブスクリプションプランを確認してください!
- **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
- HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。


