Pixel BigWave BIGO condición de carrera por timeout UAF → escritura de 2KB en el kernel desde mediacodec

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Resumen

  • Desde el contexto SELinux confinado mediacodec, /dev/bigwave (Pixel AV1 hardware accelerator) es accesible. Un acumulado de jobs hace que BIGO_IOCX_PROCESS alcance su 16s wait_for_completion_timeout() y retorne mientras el hilo worker concurrentemente desencola la misma estructura inline job.
  • Cerrar el FD libera inmediatamente struct bigo_inst (que incorpora struct bigo_job). El worker reconstruye inst = container_of(job, ...) y más adelante usa campos ya liberados como job->regs dentro de bigo_run_job(), provocando un Use-After-Free on the inline job/inst.
  • bigo_pull_regs(core, job->regs) realiza memcpy_fromio(regs, core->base, core->regs_size). Reclamando el slab liberado y sobrescribiendo job->regs, un atacante obtiene una escritura arbitraria en el kernel de ~2144 bytes a una dirección elegida, con control parcial de los bytes preprogramando valores de registro antes del timeout.

Mapeo de la superficie de ataque (SELinux → accesibilidad a /dev)

  • Usa herramientas como DriverCartographer para enumerar nodos de dispositivo accesibles desde un dominio SELinux dado. A pesar de la política restringida de mediacodec (los decoders por software deberían permanecer en un contexto aislado), /dev/bigwave permaneció accesible, exponiendo una gran superficie de ataque al código post-media-RCE.

Vulnerabilidad: BIGO_IOCX_PROCESS timeout vs worker

  • Flujo: ioctl copia el buffer de registros del usuario en job->regs, encola el job inline, luego wait_for_completion_timeout(..., 16s). En el timeout intenta desencolar/cancelar y retorna al espacio de usuario.
  • Mientras tanto bigo_worker_thread puede haber justo desencolado el mismo job:
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;
  • Si userspace cierra el FD después del timeout, inst/job se liberan mientras el worker sigue usándolos → UAF. No existe sincronización que ate la vida del FD al puntero job del worker thread.

Esquema de explotación

  1. Backlog + timeout: Encola suficientes jobs para retrasar al worker, luego ejecuta BIGO_IOCX_PROCESS y deja que llegue a la ruta de timeout de 16s.
  2. Free while in use: Tan pronto como ioctl retorna, close(fd) para liberar inst/job mientras el worker sigue ejecutando el job desencolado.
  3. Reclaim + pointer control: Spray de reclaimers (p.ej., Unix domain socket message allocations) para ocupar la ranura de slab liberada y sobrescribir el job inline, especialmente job->regs.
  4. Arbitrary write: Cuando bigo_pull_regs() se ejecuta, memcpy_fromio() escribe core->regs_size (~2144 bytes) desde MMIO a la dirección suministrada por el atacante en job->regs, produciendo un write-what-where grande sin un KASLR leak.
  5. Data shaping: Dado que los registros se programan primero desde datos de usuario (bigo_push_regs), configúralos para que el hardware no ejecute, manteniendo la imagen de registros copiada de vuelta cercana a bytes controlados por el atacante.

Conclusiones para revisores de drivers

  • Las estructuras job inline por FD encoladas a workers asíncronos deben mantener referencias que sobrevivan las rutas de timeout/cancel; cerrar un FD debe sincronizarse con el consumo por el worker.
  • Cualquier helper de copia MMIO (memcpy_fromio/memcpy_toio) que use punteros a buffers desde jobs debería ser validado o duplicado antes de encolarlo para evitar primitivas UAF→write.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks