Pixel BigWave BIGO timeout race UAF → 2KB Kernel-Schreibzugriff von mediacodec

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

TL;DR

  • From the SELinux-confined mediacodec context, /dev/bigwave (Pixel AV1 hardware accelerator) is reachable. A backlog of jobs makes BIGO_IOCX_PROCESS hit its 16s wait_for_completion_timeout() and return while the worker thread concurrently dequeues the same inline job structure.
  • Beim Schließen des FD wird sofort struct bigo_inst freigegeben (welches struct bigo_job einbettet). Der Worker rekonstruiert inst = container_of(job, ...) und verwendet später freigegebene Felder wie job->regs innerhalb von bigo_run_job(), was zu einem Use-After-Free auf dem inline job/inst führt.
  • bigo_pull_regs(core, job->regs) führt memcpy_fromio(regs, core->base, core->regs_size) aus. Indem der Angreifer den freigegebenen Slab zurückerobert und job->regs überschreibt, erhält er einen ~2144-Byte beliebigen Kernel-Schreibzugriff auf eine gewählte Adresse, mit teilweiser Kontrolle über die Bytes durch Vorprogrammieren von Registerwerten vor dem Timeout.

Attack surface mapping (SELinux → /dev reachability)

  • Verwende Tools wie DriverCartographer, um Device-Nodes aufzulisten, die von einem gegebenen SELinux-Domain aus zugänglich sind. Trotz der eingeschränkten Policy von mediacodec (Software-Decoder sollten in einem isolierten Kontext bleiben) blieb /dev/bigwave erreichbar und exponierte eine große Angriffsfläche für post-media-RCE-Code.

Vulnerability: BIGO_IOCX_PROCESS timeout vs worker

  • Ablauf: ioctl kopiert den user register buffer in job->regs, ordnet das inline job in die Queue ein und ruft dann wait_for_completion_timeout(..., 16s) auf. Beim Timeout versucht es, das job zu de-queueen/abzubrechen und kehrt in den Userspace zurück.
  • Währenddessen hat bigo_worker_thread möglicherweise gerade dasselbe job aus der Queue entfernt:
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;
  • Wenn userspace die FD nach dem Timeout schließt, werden inst/job freigegeben, während der Worker sie weiterhin benutzt → UAF. Es gibt keine Synchronisation, die die Lebensdauer der FD mit dem job-Pointer des Worker-Threads verknüpft.

Ablauf der Ausnutzung

  1. Backlog + timeout: Stelle genügend Jobs in die Warteschlange, sodass der Worker verzögert wird, rufe dann BIGO_IOCX_PROCESS auf und lasse es den 16s-Timeout-Pfad erreichen.
  2. Free while in use: Sobald ioctl zurückkehrt, close(fd) aufrufen, um inst/job freizugeben, während der Worker den dequeued job noch ausführt.
  3. Reclaim + pointer control: Spraye Reclaimer (z. B. Unix domain socket message-Allokationen), um den freigegebenen Slab-Slot zu belegen und den inline-job zu überschreiben, insbesondere job->regs.
  4. Arbitrary write: Wenn bigo_pull_regs() ausgeführt wird, schreibt memcpy_fromio() core->regs_size (~2144 bytes) von MMIO in die vom Angreifer bereitgestellte Adresse in job->regs, was einen großen write-what-where ohne KASLR leak erzeugt.
  5. Data shaping: Da Register zuerst aus Benutzerdaten (bigo_push_regs) programmiert werden, setze sie so, dass die Hardware nicht ausführt, und halte das zurückkopierte Registerabbild nahe an den vom Angreifer kontrollierten Bytes.

Erkenntnisse für Driver-Reviewer

  • Inline per-FD job structs, die in async Workers eingereiht werden, müssen Referenzen halten, die Timeout-/Cancel-Pfade überleben; das Schließen einer FD muss mit dem Verbrauch durch den Worker synchronisiert werden.
  • Alle MMIO copy helper (memcpy_fromio/memcpy_toio), die Buffer-Pointer aus Jobs verwenden, sollten vor dem Enqueue validiert oder dupliziert werden, um UAF→write-Primitives zu vermeiden.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks