soralis0912/cve-2026-43499-warhol-rootExploit de escalada de privilegios local dirigido a CVE-2026-43499 para el Xiaomi 17T Pro (warhol) en Android 16 con SoC MediaTek MT6993.
Escalada de privilegios local CVE-2026-43499 (IonStack), portada al Xiaomi 17T Pro (warhol) — MediaTek MT6993, Android 16.
Solo GKI 6.12 / android16. El overlay de waiter, el layout de la pila
pselecty cada offset de struct están anclados a esa rama, así que nada de esto se transfiere a 6.6, 6.1 o 5.10 — esos necesitan una base construida para ellos.generate_target.pyrechaza cualquier otro banner en lugar de emitir un header que fallaría en el dispositivo.
Estado: funcionando. Verificado en dispositivo el 2026-07-26 desde un arranque limpio, bajo ambas variantes de preloader —
uid=0(root) context=u:r:kernel:s0, SELinux permisivo,suinstalado. Root no es persistente: vuelve a ejecutar la líneaLD_PRELOADdespués de cada arranque. La carrera de pselect no es 100%: una ejecución fallida puede causar un panic en el teléfono, y reintentar después del reinicio es normal. ConsultaWARHOL_PORT.mdpara el registro completo.
Este dispositivo necesita el fix de kernel-MTE. El popsicle upstream de serie no puede rootearlo — se queda atascado en
kernel page retry N/12para siempre. Ver Kernel MTE.
Las builds vienen en dos variantes de preloader, PRELOADER=retail (por defecto) y PRELOADER=eng. Seleccionan directorios de target distintos para que ninguna pueda sobrescribir las direcciones de la otra — ver Variante de preloader.
Los datos siguientes se leyeron del paquete retail full-OTA — metadatos, el manifest del payload A/B y las imágenes boot/vendor_boot/dtbo extraídas de payload.bin.
| Elemento | Valor | Fuente |
|---|---|---|
| Codename | warhol | pre-device=warhol |
| Build fingerprint | Xiaomi/warhol_global/warhol:16/BP2A.250605.031.A3/OS3.0.304.0.WPSJPXM:user/release-keys | post-build |
| Incremental | OS3.0.304.0.WPSJPXM (JP global) | post-build-incremental |
| Android | 16, SDK 36 | post-sdk-level=36 |
| Parche de seguridad | 2026-05-01 | post-security-patch-level |
| Tipo de OTA | A/B (payload.bin, CrAU, 39 particiones) | ota-type=AB |
| SoC | MediaTek MT6993 (Dimensity 9500) | mediatek,mt6993-* compatibles en el DTB de vendor_boot; cmdline bootopt=64S3,32N2,64N2 |
| Kernel | 6.12.38-android16-5-g1d46253471dd-ab15048002-4k, clang 19.0.1 | banner leído de la boot.img extraída |
| Imagen boot | header v4, kernel 18.898.125 B, comprimida en LZ4-legacy, sin ramdisk | tools/bootinfo.py |
El kernel importa más que el SoC aquí: warhol está en la misma rama GKI que el popsicle upstream (android16-5, páginas de 4K), a un patchlevel de distancia — 6.12.38 frente al 6.12.23 verificado de popsicle. Los offsets de struct todavía tienen que regenerarse por build; solo la forma del exploit se traslada. Una build distinta de OS3.0.x necesita su propio target.h.
La cadena del exploit está bloqueada por versión a la rama GKI, no al SoC. El layout del waiter de rt_mutex, el overlay de pila pselect y los offsets del struct pipe_buffer siguen todos al kernel, así que una base 6.12/android16 supera a una base del mismo vendor en una rama más antigua.
x-spy/CVE-2026-43499-popsicle es la única implementación pública verificada en la línea GKI 6.12/android16 (Xiaomi 17 / Pro / Ultra, kernel 6.12.23-android16-5), así que source/ se toma de ella y se mantiene lo más cerca posible de upstream — salvo dos líneas (ver Kernel MTE, que este dispositivo necesita para funcionar en absoluto).
La mayor parte del delta MediaTek se limita a la generación de target en tiempo de build, en dos piezas:
upstream lee p0_phys_offset y p0_kernel_phys_load de una partición Qualcomm xbl_config, que warhol no tiene. generate_target.py --dtb lee la base de DRAM del nodo /memory del FDT de vendor_boot en su lugar, redondeándola hacia abajo igual que hace arm64_memblock_init. La dirección física de carga del kernel se lee de la reserva mb_kernel del preloader con --preloader; el delta sale 0 para este dispositivo, y lk se niega a arrancar un kernel colocado en cualquier otro sitio.
MediaTek distribuye el kernel comprimido en LZ4-legacy dentro de boot.img en lugar de como un Image arm64 puro, así que el generador lo descomprime antes del análisis.
WARHOL_PORT.md §2 tiene la derivación completa.
El lk de MediaTek no carga el kernel en una constante de tiempo de compilación — busca una reserva de DRAM llamada mb_kernel y comprueba que ha caído exactamente en ella. Esa reserva la hace el preloader, razón por la cual la build de preloader que ejecuta el teléfono es una entrada de build aquí: es la única cosa fuera de boot.img que puede mover P0_KERNEL_PHYS_LOAD, y un valor incorrecto ahí significa un alias de linear-map incorrecto y un teléfono muerto en lugar de un exploit fallido.
De ahí dos variantes, mantenidas como directorios de target separados:
PRELOADER= | Preloader en el teléfono | Directorio de target | Estado |
|---|---|---|---|
retail (por defecto) | el preloader_<device>.bin de fábrica, byte-idéntico al preloader_raw.img de la ROM fastboot | targets/warhol-OS3.0.304.0.WPSJPXM/ | ✅ verificado en dispositivo el 2026-07-26 |
eng | la build de ingeniería, preloader_<device>_eng.bin | targets/warhol-OS3.0.304.0.WPSJPXM-eng/ | ✅ verificado en dispositivo el 2026-07-26 |
make preload # PRELOADER=retail -> out/preload-<device>.so
make PRELOADER=eng preload # -> out/preload-<device>-eng.so
make both # both of the above, and print their sha256
Ambos artefactos se mantienen lado a lado con nombres distintos. En este firmware salen byte-idénticos — eso es el resultado del análisis siguiente, no un atajo para evitarlo, así que los dos se siguen compilando y nombrando por separado.
Lee tú mismo las tablas de memory-layout de los dos preloaders con:
python3 tools/preloader_memlayout.py <preloader.bin> --diff <preloader_eng.bin>
Para este firmware las dos tablas son idénticas, mb_kernel.start = 0x80000000 en ambas, así que el target.h de eng sale byte-idéntico al de retail y ambas builds producen el mismo preload.so.
Lo que realmente llega al exploit es la diferencia P0_KERNEL_PHYS_LOAD − P0_PHYS_OFFSET, y sus dos términos no se apoyan en evidencia igualmente sólida:
P0_KERNEL_PHYS_LOAD — medido a partir de la imagen eng, como mb_kernel.start arriba.
P0_PHYS_OFFSET — fue argumentado más que medido, ya que es memstart_addr, que el kernel toma del nodo /memory que lk emite en runtime a partir de lo que el preloader reporta tras el init de DRAM, no del FDT estático que lee el generador. El argumento fue que las dos builds comparten todo el camino de DRAM — mismas fuentes dramc/emi/mblock/memory_layout, sin código de memory-layout entre las cadenas exclusivas de eng — y que la única reserva extra del preloader eng, una security_fe_rsv dinámica de 3 MiB con mapping=1, no puede desplazar una entrada de dirección fija ni tallar un hueco en el fondo de la DRAM. La ejecución en el dispositivo lo zanjó: los alias de linear-map cayeron bajo eng, así que el término es correcto.
Derivación completa en targets/warhol-OS3.0.304.0.WPSJPXM-eng/NOTES.md.
Notas de la ejecución en el dispositivo:
ro.boot.verifiedbootstate=green y flash.locked=1 sin cambios. Esa era una cuestión abierta hasta que se probó; la decide el hash de la root key en efuse, y esta build está firmada con las mismas claves que retail.