CVE-2026-5281+CVE-2026-11057 Cadena de explotación completa de Android

Dispositivo

Pixel 7 Android 16 ARM64

Versión de Chromium

commit 994c846bbd7a35241ba7c08158c13d66412a6993 (HEAD -> 146.0.7680.111, tag: 146.0.7680.111)
Author: Roger McFarlane <[email protected]>
Date:   Mon Mar 9 12:48:07 2026 -0700

Descripción

Enfoque de explotación

Este repositorio combina CVE-2026-11057 (memoria de imagen de glifo no inicializada en Skia) y CVE-2026-5281 (use-after-free de DeviceInfo en el servidor wire de Dawn) en una cadena completa. Todas las modificaciones son del lado del renderer; el código del proceso GPU no se modifica:

1. Fuga de información (CVE-2026-11057) — Activar un búfer de imagen de glifo no inicializado mediante el renderizado de texto en canvas, leer punteros del heap del proceso GPU, validarlos con ejecuciones aritméticas, derivar la base del pool de PartitionAlloc y calcular el objetivo falso de Server M = POOL + 0x202A08000 (offset calibrado).

2. Rocío de CC — createBuffer(label="CCM:<m>:<n>") provoca la inyección de 3000 ChunkedCommands incompletos (bucket de 10KB, remainingSize=1, mantenidos vivos en mChunkedCommands del servidor wire). El payload llena la región alrededor de M con un Server falso dispuesto para Android arm64: vptr de MutexProtected en +0xB20, ChunkedCommandSerializer en +0xB50/+0xB58, CommandSerializer/vtable falsos en +0xC00/+0xD00.

3. Disparo de 5281 + ocupación — queue.writeBuffer(buffer, 0x414141, ...) primero llama a Unregister(Device) para liberar el DeviceInfo de 16 bytes, luego inyecta un ChunkedCommand de ocupación de 16 bytes para reclamar esa ranura y sobrescribir info->server con M, y finalmente provoca un error de validación con un offset fuera de límites.

4. Callback colgante → secuestro de vtable — El callback de error no capturado desreferencia info->server = M (Server falso): los mutexes puestos a cero pasan, la ejecución llega a OnUncapturedError → SerializeCommand, y la llamada indirecta relativa a la vtable alcanza nuestra vtable falsa, dando pc = fake_vtable + offset int32 controlado, demostrado con pc = 0x7641414141.

Nota: Chromium para Android arm64 usa vtables relativas (-fexperimental-relative-c++-abi-vtables); las entradas de la vtable son offsets relativos de 32 bits en lugar de punteros de función absolutos, por lo que el PoC usa un offset int32 controlado como marcador en el punto de secuestro de la vtable.

En el dispositivo de prueba, la cadena completa alcanza el crash por secuestro de vtable con una tasa de éxito de casi el 100%; la etapa de fuga puede requerir ocasionalmente varias recargas automáticas antes de tener éxito.

Roles de los archivos

• SkStrike.cpp.patch — Disparador de fuga de CVE-2026-11057. FlattenGlyphsByType() reescribe el payload del strike para que el proceso GPU cree un SkGlyph con fImage == nullptr, leyendo finalmente un búfer de imagen no inicializado para filtrar punteros del heap.
• Device.cpp.patch — Rocío de CC del cliente wire de Dawn. APICreateBuffer() analiza la etiqueta CCM:, construye el payload del Server falso para Android arm64 e inyecta N ChunkedCommands incompletos que permanecen vivos en el proceso GPU.
• ApiProcs.cpp.patch — Disparo de CVE-2026-5281 + ocupación. En el offset mágico 0x414141 de QueueWriteBuffer, llama a Unregister(Device) para liberar DeviceInfo, inyecta un ChunkedCommand de 16 bytes para reclamar la ranura y establecer info->server = M, y luego continúa con un offset fuera de límites para disparar el callback colgante.
• exploit.html — Orquestación de la página: primitiva de fuga (groom/draw/readCell/verifyRuns/derivePoolBase), rocío de CC y un disparador independiente exploit5281(); en caso de fallo, limpia el estado del rocío y recarga para que las etapas no interfieran.

Alcance de la divulgación

Este ExP solo se divulga hasta el paso de secuestro de vtable (objetivo de llamada indirecta controlado, pc = base+0x41414141). Los pasos a partir del salto controlado, así como la implementación de RCE, se mantienen confidenciales y no se incluyen en este repositorio.

Exploit del mundo real vs. PoC original

Mi exploit difiere del enfoque del reportero original en un aspecto clave. El exploit original se logró modificando el código fuente de PartitionAlloc en el proceso GPU para deshabilitar la aleatorización de direcciones. Este enfoque solo es adecuado para fines de prueba de concepto. En cambio, mi exploit combina una vulnerabilidad de divulgación de información para eludir la aleatorización de direcciones, lo que permite un exploit totalmente funcional que funciona en entornos del mundo real.

Build args.gn

# Set build arguments here. See `gn help buildargs`.
is_official_build = true
is_debug = false
symbol_level = 0
v8_symbol_level = 0
blink_symbol_level = 0
is_component_build = false  
proprietary_codecs = true   
ffmpeg_branding = "Chrome"  
dcheck_always_on =false
optimize_webui = true
android_static_analysis = "off"
target_os = "android"
target_cpu = "arm64"

# Disable PartitionAllocEventuallyZeroFreedMemory
disable_fieldtrial_testing_config = true

treat_warnings_as_errors = false

Reproducción

1. cd third_party/dawn
2. git apply ApiProcs.cpp.patch
3. git apply Device.cpp.patch
4. cd ../skia
5. git apply SkStrike.cpp.patch
6. Compilar chromium
7. Abrir Chrome en un dispositivo Android y ejecutar exploit.html
8. Ejecutar adb logcat | grep DEBUG en el PC

Nota

1. Tener cuidado con el problema de PartitionAllocEventuallyZeroFreedMemory. Cuando está habilitado, eventualmente pone a cero la memoria liberada. Esta característica está deshabilitada por defecto. En las compilaciones oficiales Stable está controlada por Finch de Google (prueba de campo del lado del servidor) y Google generalmente no la activa para la población general. Sin embargo, con frecuencia se habilita en compilaciones locales / no oficiales y en los canales oficiales Dev/Canary (especialmente cuando las configuraciones de prueba de campo están activas). Este es un problema común al desarrollar o probar exploits contra compilaciones no Stable.
2. Acceder a exploit.html a través de la dirección de loopback 127.0.0.1. De lo contrario, HTTP se tratará como no confiable y WebGPU no funcionará
3. En este caso de uso, el diseño del heap de la primitiva de fuga funciona particularmente bien en Pixel 7, requiriendo solo de 1 a 10 segundos. También tiene éxito en Pixel 9, aunque el proceso tarda de 2 a 3 minutos. Si bien el diseño del heap puede optimizarse aún más para una mayor compatibilidad en la mayoría de los dispositivos Pixel —y dichas mejoras ya se han identificado—, estas optimizaciones quedan fuera del alcance de este experimento y no se analizan aquí.