Reproducción de CVE-2025-21479: root temporal en vivo iQOO 11 Pro (PD2254)

Investigación de seguridad autorizada en dispositivos propios. CVE-2025-21479 es una vulnerabilidad de la GPU Qualcomm Adreno, pública, ya corregida (2025-08) e incluida en la lista CISA KEV. Este documento registra el proceso completo y la entrega final de la reproducción del root temporal en el iQOO 11 Pro.

1. Resumen de la vulnerabilidad

• CVE: CVE-2025-21479 (CVSS 8.6, CWE-863 Incorrect Authorization)
• Componente: firmware de la GPU Qualcomm Adreno (a740_sqe.fw)
• Causa raíz: defecto en la condición de filtrado de la instrucción de microcódigo and $04, $12, 0x3 del firmware v675 (la versión corregida usa 0x7), que permite que el flujo de comandos en modo usuario omita las comprobaciones de permisos, ejecute operaciones privilegiadas de la GPU (secuestro de las tablas de páginas de la SMMU) y, finalmente, obtenga lectura/escritura arbitraria de memoria física
• Impacto: serie Adreno A7xx (Snapdragon 8 Gen 1/2/3, etc.)
• Corrección: boletín de Qualcomm de 2025-06 / parche de seguridad de Google de 2025-08 (firmware v676+)

2. Dispositivo objetivo

El firmware de Android 16 (16.3.10.1) ya está corregido; esta reproducción solo es aplicable a Android 15 (15.2.12.2).

3. Fuentes de la reproducción

• zhuowei/cheese (Quest 3/3S, Adreno 740)
• ma4the/omae-wa-cheese-da (Galaxy Z Flip5, SM8550/Adreno 740 v675)

4. Trabajo de portabilidad

4.1 Verificación de disponibilidad de la vulnerabilidad (sin conexión)

• Se extrajo a740_sqe.fw del paquete OTA completo: 75.380 bytes; la búsqueda del patrón de instrucción vulnerable 0300 422a (and $04,$12,0x3) encontró 3 coincidencias → sin corregir
• El mismo archivo en el paquete de Android 16 no contiene el patrón → corregido

4.2 Extracción de material del kernel (sin conexión)

• boot.img → kernel.raw → vmlinux-to-elf para recuperar símbolos
• Símbolos clave: _text=0xffffffc008000000, _stext=0xffffffc008010000, swapper_pg_dir, selinux_state, init_task
• Desplazamientos de estructuras BTF (task_struct / mm_struct / cred)
• Verificación de KASLR: el _stext físico está fijado en 0xa8010000 (PHYS_OFFSET=0xA8000000, diseño estándar de SM8550); en el lado VMLINUX se verifica 0xffffffc008010000

4.3 Puntos clave de portabilidad (respecto a omae-wa-cheese-da)

1. Constantes de KASLR: las VA de swapper_pg_dir / init_task / selinux_state se sustituyen por los valores de A15
2. Bypass de SELinux: escritura física de selinux_state.enforcing=0. Se ha verificado que el kernel A15 de PD2254 incluye CONFIG_SECURITY_SELINUX_DEVELOP=y (los símbolos sel_write_enforce/enforcing_setup existen en kallsyms), y enforcing_enabled() lee el campo en tiempo de ejecución → la escritura surte efecto y getenforce muestra Permissive
3. Adaptación de los candidatos del GPU spray (crítico): los candidatos de Samsung (0xbe..-0xfe..) caen en la región reservada del dispositivo de vivo de 2-4 GB; por encima de 4 GB (0x100000000) se dispara una falta de SMMU de la GPU que reinicia el dispositivo. Estrategia combinada = clúster verificado 0xfebeb000 + candidatos adyacentes en 2-4 GB + dispersión en la zona alta de 5-11 GB → la tasa de acierto mejora drásticamente
4. Materialización del root (solo caps, contramedida principal contra el anti-root de vivo): el de vivo (módulo integrado en vendorboot) mediante hooks de kprobe/tracepoint + un hilo daemon, y además el módulo se auto-oculta y verifica el vermagic. Por eso no se pone el uid a cero; en su lugar se reescriben físicamente los bits de capability del cred (uid se mantiene en 2000 + todas las caps + /) → el conjunto completo de capacidades se conserva a través de exec, lo que equivale a root sin activar el watchdog

5. Resultados de la verificación (en dispositivo real)

Registro de éxito (primera ejecución; el dispositivo estaba inicialmente en Enforcing; se siguió la ruta de escritura física de enforcing):

phyaddr: 0xfebeb000 (attempt 1/27)        # spray 候选命中
GPU R/W ready                             # 任意物理读写建立
found _stext at 0xa8010000                # KASLR 泄漏（扫描路径；显式 CHEESE_STEXT_PA 时无此行）
FW symbols resolved
stext = 0xa8010000                        # 物理 _stext = VA - 0xffffffc000000000 + 0xA8000000
SELinux enforcing overwrite verified (readback=1 enforce=0)
self creds: full caps granted (uid=2000 kept, watchdog dodge)
root shell (uid=2000, full caps kept)...

Si se ejecuta una segunda vez en la misma sesión (SELinux ya está en modo permisivo), esa línea cambia a SELinux already permissive.

6. Instrucciones de uso

# 设备刷入 Android 15 (15.2.12.2) 后：
adb push cheese /data/local/tmp/
adb shell chmod 755 /data/local/tmp/cheese
adb shell CHEESE_STEXT_PA=0xa8010000 /data/local/tmp/cheese
# 完成后当前 adb shell 会话即为 root shell（uid=2000 + 全 caps），SELinux 宽容模式

Variables de entorno:

Reintento automático: bash cheese_auto.sh (se ejecuta en bucle, detecta reinicios sin conexión y guarda los registros en disco).

7. Notas importantes

• Root temporal: debe volver a ejecutarse tras cada reinicio; SELinux vuelve a Enforcing
• El GPU spray es probabilístico: si falla, basta con reintentar (la tasa de acierto en la primera ronda es alta con los candidatos combinados)
• Algunos candidatos de la zona alta pueden provocar una falta de GPU y reiniciar el dispositivo (inofensivo; tras el reinicio se reintenta automáticamente)
• Limitaciones conocidas: el vr.ko de vivo mata los procesos con uid=0 y el módulo se auto-oculta; no se ha implementado persistencia ni integración con KernelSU (los módulos de KernelSU no se pueden cargar con insmod porque el kernel no exporta los símbolos; ver apéndice)
• Uso exclusivo para investigación de seguridad autorizada en dispositivos propios

8. Lista de archivos

• cheese: artefacto compilado (ELF de Android aarch64, NDK r28; entrega en binario, código fuente no público)
• cheese_auto.sh: script de reintento automático
• README.md: este documento

Apéndice: mecanismo anti-root de vivo (vr.ko)

• Origen: lib/modules/5.15-gki/vr.ko dentro de vendorboot.img (389 KB)
• Mecanismo: hooks de kprobe/tracepoint + hilo daemon que monitoriza y mata los procesos con uid=0; tras cargarse se auto-oculta, y rmmod deja de funcionar
• Conclusión del análisis: el setuid normal, la modificación física del cred con uid=0 y la herencia por procesos hijo son eliminados → la única ruta estable es solo caps (uid≠0 + todas las caps)

Descargo de responsabilidad

Este repositorio se utiliza únicamente con fines de investigación y educación en seguridad; todas las pruebas se han realizado en dispositivos propios del autor. Úselo únicamente dentro del ámbito de la autorización legal; el usuario asume todos los riesgos.