CVE-2026-43499 — aristotle (au/KDDI Xiaomi XIG04)

Lokale Privilegienerweiterung (tmp-root) für das au/KDDI Xiaomi „aristotle“ (XIG04) unter Android 12, über CVE-2026-43499. Es handelt sich um eine Device-Owner-Rooting-Primitive: Sie rootet das eigene Telefon (z. B. um ADB wieder zu aktivieren, wenn die Entwickleroptionen nicht erreichbar sind).

Dies ist ein aristotle-Port der Upstream-Implementierung: https://github.com/x-spy/CVE-2026-43499-popsicle — die auf das Xiaomi 17 / Pro / Ultra (popsicle, Snapdragon, Android 16, Kernel 6.12.23) abzielt. Die gesamte Anerkennung für die Exploit-Technik gebührt Upstream; dieser Fork richtet sie lediglich auf ein anderes Gerät und eine andere Kernel-Generation neu aus.

Umfang: das eigene XIG04 mit Xiaomi/XIG04_jp_kdi/XIG04:12/SP1A.210812.016/V14.0.3.0.TMFJPKD. Kein Allzweck- oder Remote-Exploit.

Ziel

device  : aristotle (au/KDDI XIG04), MediaTek, Android 12
kernel  : 5.10.136-android12-9-00020-gc9f59ef34367-ab9585114  (VA=39, 4K pages, KASLR)

Der Fehler

CVE-2026-43499 ist ein Use-after-Free im Linux-Kernel-Futex-PI-Pfad: remove_waiter() in kernel/locking/rtmutex.c arbeitet auf current statt auf waiter::task während des Proxy-Lock-Rollbacks von futex_requeue(), wodurch ein hängender pi_blocked_on zurückbleibt. Es ist ein alter, langlebiger Fehler (betroffen: Linux 2.6.39 – 6.18.x), daher liegt der hiesige Kernel 5.10.136 im betroffenen Bereich (CONFIG_FUTEX_PI=y, CONFIG_RT_MUTEXES=y). Der Exploit nutzt einen rein datenbasierten „Direct-Root“ (Tausch von cred → init_cred, Deaktivieren von SELinux-Enforcing) und erzwingt MTE-Tags, um die Härtung des Geräts zu überleben (KASAN_HW_TAGS, MTE, , ).

Was sich von Upstream unterscheidet (popsicle → aristotle)

Upstream zielt auf Snapdragon / Android 16 / Kernel 6.12; aristotle ist MediaTek / Android 12 / Kernel 5.10, daher leitet der Port alles gerätespezifische neu ab:

• rt_mutex_waiter ist das alte flache 5.10-Layout (kein verschachtelter rt_waiter_node, kein wake_state/ww_ctx). Die Fake-Waiter-Tabellen in source/src/{slide,fops}.c und source/src/util.c wurden von 13 Wörtern auf 10 umgebaut.
• Kein xbl_config. KASLR wird dynamisch überwunden (Kernel-Info-Leak in slide.c); die beiden physikalischen Konstanten, die Upstream aus dem Qualcomm-XBL übernahm, werden durch eine statische DRAM-Basis (0x40000000, aus dem Device Tree) plus Laufzeit-memstart_addr / kimage_voffset ersetzt.
• Kein BTF in diesem Kernel, daher werden die Strukturoffsets durch Disassemblierung ermittelt und injiziert, statt aus BTF gelesen.
• Alle Offsets, RVAs und KASLR-Anker wurden für genau diesen Kernel gemessen — siehe ARISTOTLE_CVE43499_PORT.md.

Ziel-Header erzeugen

Eine vermessene source/src/target.h für XIG04 ist bereits eingecheckt, sodass direkt gebaut werden kann. Zur Neugenerierung aus einem Boot-Image den aristotle-Generator verwenden (kein --xbl-config; er emittiert memstart_addr/kimage_voffset-RVAs zur dynamischen Verwendung):

python3 gen_aristotle_target.py \
  --boot boot.img \
  --pselect-shift 0 \
  --loggers 0xffffffc012771380 \
  --boot-id-data 0xffffffc012886cf8 \
  --kernel-phys-load 0x40080000 \
  -o source/src/target.h

(Die drei Anker und der Kernel-Phys-Load sind die Werte, die im eingecheckten Header fest verdrahtet sind; siehe ARISTOTLE_CVE43499_PORT.md für deren Ermittlung.)

Bauen

Benötigt Python 3 und das Android-NDK (r29). API=31 ist erforderlich, damit die Payload unter Android 12 geladen wird:

make -C source clean preload API=31

Falls das NDK nicht automatisch erkannt wird:

NDK_ROOT=/path/to/android-ndk make -C source clean preload API=31

Endgültiges Artefakt:

source/build/bin/preload.so

Ausführen

adb push source/build/bin/preload.so /data/local/tmp/preload.so
adb shell 'chmod 0644 /data/local/tmp/preload.so'
adb shell 'LD_PRELOAD=/data/local/tmp/preload.so /system/bin/true'
adb shell '/data/local/tmp/su -c id'

Bei Erfolg:

uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
direct-root-summary root=1 id=1 su=1/... selinux=1->0 uid=0 euid=0 gid=0 egid=0

preload.so enthält und installiert beim Laden selbst seinen eigenen su-Client plus -Daemon, sodass keine separate su-Binärdatei benötigt wird.

Status: Der Port ist aus statischer Analyse codevollständig, aber noch nicht auf Hardware validiert. Zuerst den Crash-Trigger validieren, dann Root, auf dem eigenen Gerät. Kernelspezifische Abstimmungspunkte (MM_ORDER, P0_KERNEL_PHYS_LOAD, das Flat-Waiter-Verhalten) sind in ARISTOTLE_CVE43499_PORT.md aufgelistet.