Kernel-Exploit-Research — Xiaomi 5.4-qgki (veux & moonstone)

Datum: 2026-10-07/08 Geräte: Redmi Note 11 Pro 5G (veux, 5.4.274-qgki) & POCO X5 5G (moonstone, 5.4.191-qgki) SoC: Snapdragon 695 (SM6375)

---

Zusammenfassung

CVE	Status	Anmerkungen
CVE-2026-43284 (DirtyFrag)	❌ Tot	Benötigt MSG_SPLICE_PAGES (Kernel 6.5+)
CVE-2026-24088 (Qualcomm fastboot)	⚠️ Bootloader-spezifisch	TheFliss: „unknown command" auf seinem Gerät
CVE-2022-2602 (io_uring UAF)	❌ Tot	Kernel blockiert den Register-Pfad (EFAULT/EINVAL)
CVE-2022-20421 (BadSpin)	❌ Versucht, kein Erfolg	Kompiliert OK, läuft in Schleife ohne Race zu gewinnen
CVE-2023-20938 (binder UAF)	✅ Anfällig (beide)	Noch nicht versucht
CVE-2023-4622 (af_unix UAF)	✅ Anfällig (beide)	Noch nicht versucht
CVE-2026-43499 (GhostLock)	❓ Möglicherweise anfällig	GhostLock-App funktioniert auf 5.4 konstruktionsbedingt nicht
KGSL CVEs (5x)	❓ Möglicherweise anfällig	2024-38399 hat Writeup+PoC

---

1. DirtyFrag (CVE-2026-43284)

Urteil: Auf 5.4 nicht machbar.

Der Bug existiert in 5.4 (Code aus 4.11), aber der Exploit benötigt MSG_SPLICE_PAGES-UDP-Unterstützung für das Page-Cache-Schreib-Primitiv. Diese wurde in Kernel 6.5 eingeführt. Auf 5.4 führt splice() zu UDP eine reguläre Kopie durch — keine gemeinsame Seitenanbindung.

CVE-2026-43500 (RxRPC-Variante) ist ebenfalls nicht anwendbar — RxRPC-Code wurde in 6.8 eingeführt.

Repo: https://github.com/HirokiAkihiko/dirtyfrag-research

---

2. CVE-2026-24088 (Qualcomm ABL Fastboot)

Urteil: Bootloader-spezifisch, nicht universell.

Bug in Qualcomm ABL: fastboot oem set-gpu-preemption bereinigt Argumente nicht, was die Injektion von androidboot.selinux=permissive in die Kernel-Cmdline ermöglicht.

• Betrifft SM6375 (bestätigt durch Drittanbieter-Research)
• Kein Bootloader-Unlock nötig
• Tethered (muss bei jedem Boot wiederholt werden)

Testergebnis (TheFliss): FAILED (remote: 'unknown command') — sein Bootloader implementiert den Befehl nicht. Diese CVE hängt vom spezifischen ABL-Build ab.

---

3. CVE-2022-2602 (io_uring UAF)

Urteil: Tot auf diesen Geräten. Der Kernel blockiert den Register-Pfad aktiv.

Geleistete Arbeit:

• PoC von x86_64 auf ARM64 Android portiert (kein liburing, minimale Helfer eingebettet)
• Mit NDK r27d kompiliert → 2,2 MB statisches Binary
• Gerätetests via LADB mit 4 Diagnose-Binaries

Erkenntnisse:

• CONFIG_IO_URING=y bestätigt
• io_uring_setup funktioniert mit einfachen Flags (SQPOLL blockiert → benötigt CAP_SYS_ADMIN)
• IORING_REGISTER_FILES → EFAULT (konsistent, auch via rohem SVC)
• IORING_REGISTER_BUFFERS → EINVAL
• Fazit: Blockade auf Kernel-Ebene beim io_uring-Register-Pfad, nicht SELinux/seccomp

Das UAF-Primitiv erfordert ein erfolgreiches IORING_REGISTER_FILES. Ohne dieses kann die Exploit-Kette nicht fortgesetzt werden.

Bundle: ~/workspace/cve-2022-2602-bundle/ (Quellcode, Binaries, Diagnose)

---

4. CVE-2022-20421 (BadSpin)

Urteil: Kompiliert und läuft, hat aber auf veux keinen Erfolg.

Geleistete Arbeit:

• Quelle: mateusvdcastro/badspin
• Für veux angepasst:
  • SPL-Prüfung in exploit.c (find_dev_config()) entfernt
  • veux-Geräteeintrag in dev_config.h hinzugefügt (Modell 2201116SG, Android 13, Kernel 5.4.274, SPL 2024-12)
• Via GitHub Actions (NDK r27d) gebaut → libbadspin.so (345K, ARM64)
• Auf dem Gerät via LADB mit TEST_VULN=1 getestet

Testergebnis: dev_config_init schlug zunächst fehl (SPL-Monatsabweichung: Eintrag hatte month=1, Gerät hat 2024-12). Via GitHub behoben. Nach dem Fix läuft der Exploit und löst die Schwachstelle aus („Trigger use-after-free"), durchläuft aber endlos ohne die Race Condition zu gewinnen.

Repo: https://github.com/HirokiAkihiko/badspin-veux (privat)

---

5. Verbleibende Kandidaten (als anfällig verifiziert, noch nicht versucht)

CVE-2023-20938 (binder UAF)

• Status: Anfällig auf veux und moonstone
• Fix-Commits bdc1c5fac982 und 4df153652cc4 nicht im Xiaomi-Quellcode vorhanden
• Nächstes empfohlenes Ziel

CVE-2023-4622 (af_unix UAF Race)

• Status: Anfällig auf beiden Geräten
• Fix 4821df2ffe38 nicht vorhanden; skb_peek_tail weiterhin lockless
• Race Condition — schwieriger zuverlässig zu machen

CVE-2026-43499 (GhostLock/futex)

• Status: Möglicherweise anfällig (Muster current->pi_blocked_on = NULL vorhanden)
• Hinweis: Die GhostLock-App selbst funktioniert konstruktionsbedingt nicht auf 5.4 (Timing-Problem)

KGSL-CVEs (Adreno-GPU)

• CVE-2023-33106, CVE-2023-33107, CVE-2023-33021, CVE-2024-38399, CVE-2025-27038
• Status: Möglicherweise anfällig (keine KGSL-Updates seit 2023-06 auf veux)
• CVE-2024-38399 hat einen öffentlichen Writeup + PoC
• GPU-Exploits sind komplex

---

Zentrale Erkenntnis

Versionsbezeichnungen sind irreführend. veux-r-oss ist als 5.4.274 gekennzeichnet, aber es fehlen stabile 5.4.y-Backports, die vorhanden sein sollten (Binder-Fixes von 2023-06, af_unix- Fix von 2023-08). Immer auf Code-Ebene verifizieren, nicht anhand der Versionsnummer.

---

Dateien & Repos

• DirtyFrag-Recherche: https://github.com/HirokiAkihiko/dirtyfrag-research (öffentlich)
• BadSpin veux: https://github.com/HirokiAkihiko/badspin-veux (privat)
• CVE-2022-2602-Bundle: ~/workspace/cve-2022-2602-bundle/
• CVE-Hunt-Nachweise: ~/workspace/cve-hunt/