CVE-2026-43499 · Honor WIN RT (AAK-AN00) Notes de recherche sur le root temporaire

(tout a été écrit par deepseek, je n'y comprends rien)

Le Bootloader de l'appareil est verrouillé en permanence (ro.oem_unlock.supported est vide), pas de fastboot, pas de su persistant, pas de Magisk. La seule voie encore praticable est une vulnérabilité du noyau. Ce dépôt documente le processus complet, de « est-ce exploitable » à « à quel point c'est stable une fois exploité ».

Nature : root temporaire, invalide après redémarrage.

Avertissement

Ce dépôt documente un processus de recherche de sécurité mené sur mon propre appareil, dans le but de comprendre les causes et les limites de stabilité d'une condition de course PI du noyau.

• Ne contient aucun binaire exploit ni charge utile directement exécutable — les charges utiles et le framework proviennent de projets publics en amont ; ce dépôt ne fait que les citer, sans les redistribuer.
• Ne fournit pas de tutoriel pour contourner les protections d'un constructeur spécifique, et n'encourage pas l'utilisation sur des appareils non autorisés.
• Les offsets et adresses de symboles présents dans ce dépôt ne sont valides que pour le build de noyau listé dans ce document ; tout changement de noyau les rend caducs.
• Les défauts concernés sont déjà corrigés en amont (voir ci-dessous). La valeur à long terme de ce document réside dans « ce compte rendu lui-même » — un retour d'expérience réel sur une vulnérabilité de course dans des conditions non idéales, y compris tous ses effets secondaires désagréables.

0. Conclusion en une phrase

Le seul chemin qui a fonctionné est :

CVE-2026-43499 (course PI futex write-what-where) + porteuse rt_sigreturn
  → injection LD_PRELOAD dans un processus du domaine shell
  → en deux étapes : d'abord passer SELinux en Permissive, puis modifier task->real_cred / cred en init_cred
  → uid=0(root) context=u:r:kernel:s0, et implantation d'un démon su

Mais ce qui mérite vraiment d'être écrit, ce n'est pas « comment obtenir root » — c'est ce qui se passe après.

Ce qu'on obtient n'est pas un root stable, mais un « état susceptible d'exploser à tout moment ».

La primitive d'écriture de l'exploit insère un rt_mutex_waiter falsifié dans la chaîne PI futex réelle, et le support de ce waiter est une pile noyau / page pulvérisée réutilisée par les appels système suivants. Ainsi, dès l'instant où root est obtenu, toute ordonnancement ou changement de priorité au niveau système peut le déclencher, provoquant directement un panic du noyau et un redémarrage. Ce n'est pas un bug, c'est le coût inhérent de cette technique d'exploitation — voir docs/03.

1. Périmètre d'application (toute non-conformité invalide l'ensemble de la solution)

Pourquoi la version du noyau doit être strictement respectée : le défaut est corrigé dans 6.6.140, et cette machine est en 6.6.118 < 6.6.140, donc toujours vulnérable ; de plus, toutes les adresses de symboles noyau et la « géométrie de la porteuse » de l'exploit sont ancrées sur ce build précis ; après un changement de noyau, la table d'offsets devient immédiatement caduque, et généralement sans retour possible.

2. Vue d'ensemble du chemin d'élévation de privilèges

┌─ Matériaux ────────────────────────────────────────────┐
│ boot.img + xbl_config.elf (extraits du firmware de l'appareil) │
│        ↓ résolution de symboles                         │
│ target.h (adresses de symboles noyau, vérifiées octet par octet avec kallsyms) │
│        ↓ compilation                                    │
│ preload.so ──► /data/local/tmp/*.so sur l'appareil      │
└────────────────────────────────────────────────────────┘
                 ↓  injection LD_PRELOAD
     ┌──────────── en deux étapes (deux processus distincts obligatoires) ────────────┐
     │ Étape A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Étape B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (réalisé par le processus « écrivain pré-positionné ») │
     │         → setresuid(0,0,0) normalisation                    │
     │         → implantation d'un su embarqué + daemon            │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Trois points à ne pas rater (une erreur bloque tout ou provoque un panic immédiat) :

1. Règle d'ordre absolue : d'abord real_cred, ensuite cred. L'ordre inverse donne instantanément tous les privilèges et fait perdre le contrôle des threads.
2. Entre les deux écritures, il existe nécessairement un état transitoire où cred ≠ real_cred. À ce moment, tout sched_setaffinity renvoie EPERM → blocage complet du cycle. La solution correcte est de forker le processus « écrivain pré-positionné » avant la première écriture (identifiants propres) ; le processus père effectue la première écriture, l'écrivain effectue la seconde, et aucun des deux n'émet d'appel système pendant l'état transitoire.
3. Le modèle d'adresses est indépendant de KASLR. Toute l'exploitation passe uniquement par l'alias de la projection linéaire alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), stable à travers les redémarrages ; la véritable valeur de la « phase slide » est l'auto-vérification de la primitive d'écriture, et non le contournement de KASLR.

Framework amont : Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Attention, ce n'est pas GhostLock — GhostLock passe par la voie pselect, et la géométrie du point de chute du waiter ne correspond pas à ce build, voir docs/06.

3. Sommaire

4. Chronologie

5. Un mot pour ceux qui suivront

Si vous aussi vous ciblez un modèle dont le BL est verrouillé, réfléchissez d'abord à ce que vous voulez faire avec root, car sur ce type de modèle, root n'est probablement qu'une fenêtre utilisable de quelques dizaines de minutes. Listez les opérations qui « nécessitent root et doivent survivre au redémarrage », exécutez-les en une seule fois, puis reboot pour revenir à un état propre. N'essayez pas d'« éliminer les effets secondaires » — c'est le coût inhérent de la technique elle-même.