CVE-2026-43499 GhostLock — ARM32 Huawei Watch 4 Pro

Tentative d'exploitation de la vulnérabilité d'élévation de privilèges du noyau Linux basée sur CVE-2026-43499 (GhostLock) — Huawei Watch 4 Pro (MDS-AL00, armv7l)

Aperçu du projet

Ce projet est une tentative d'exploitation de la vulnérabilité GhostLock du noyau sur le device Huawei Watch 4 Pro (MDS-AL00, Snapdragon SW5100, HarmonyOS 4.3.0 AOSP 12), adaptée à l'architecture ARM 32-bit (armv7l).

GhostLock (CVE-2026-43499) est une vulnérabilité UAF futex PI du noyau Linux affectant les versions 2.6.39 à 7.x. L'objectif de ce projet est de réaliser une chaîne complète d'élévation de privilèges sur la montre Huawei.

Dépôt d'origine : MobiusM/CVE-2026-43499 (PoC pour arm64)

Informations sur le périphérique

État actuel du projet

Problèmes de blocage centraux

1. Le deuxième rb_erase ne se déclenche pas (problème le plus fondamental)

Sur le noyau 5.4.161 ARM32, après le déclenchement de EDEADLK par FUTEX_CMP_REQUEUE_PI, la traversée de la chaîne PI n'exécute pas le deuxième rb_erase. L'exploitation en chaîne de GhostLock 64, qui repose sur UAF → écriture du deuxième rb_erase dans la page UAF, est totalement inefficace sur ce noyau.

Toutes les variantes de spray writev 8-iov échouent : sc[0] after = e3a0002a (la page de shellcode n'est pas écrite).

2. iovstack et rt_mutex_waiter ne sont pas alignés

Le spray writev 8-iov de ghostlock64 dépend du chevauchement du tableau iovstack[8] sur la pile du noyau avec la structure rt_mutex_waiter. Sur ce noyau :

• 11 décalages différents testés × enfant gauche/droit = 22 configurations
• Aucune ne parvient à écraser clear_refs_operations.write
• Raison probable : la disposition de la pile de ce noyau (taille du cadre, position des variables locales) diffère de celle supposée par ghostlock64

3. La traversée de la chaîne PI par sched_setattr manipule les données du propriétaire

sched_setattr déclenche avec succès la traversée de la chaîne PI (vérifié success=1600+), mais rb_erase opère sur pi_tree_entry du thread OWNER (situé dans task_struct sur le tas kmalloc), et non sur les données de pile du thread waiter (données fd_set writev).

Par conséquent, la voie pselect + sched_setattr ne peut pas non plus être utilisée pour contrôler la valeur écrite.

4. Restrictions supplémentaires du noyau Huawei

• mmap(0, ..., MAP_FIXED, ...) retourne -EINVAL, pas le -EACCES standard de Linux
• CONFIG_SECURITY_SELINUX_DEVELOP=n → le champ selinux_state.enforcing n'existe pas
• mremap → ENOSYS

Voies tentées

Adresses clés (System.map de MDS-AL00)

commit_creds:           0xC0140390
prepare_kernel_cred:    0xC014059C
proc_clear_refs_ops:    0xC0CAF280  (.write @ +12 = 0xC0CAF28C)
mmap_min_addr:          0xC12E8568
dac_mmap_min_addr:      0xC123C734
selinux_hooks[mmap]:    0xC0F64E1C

Références externes (ARM64, non directement applicables)

Les deux dépôts utilisent pselect() + sched_setattr pour déclencher la chaîne PI + écriture directe physmap, en s'appuyant sur le mécanisme de mappage direct de l'ARM64. L'ARM32 n'a pas de mappage direct, et le comportement de la chaîne PI de ce noyau est différent.

Structure des fichiers du dépôt

CVE-2026-43499-armv7/
├── config/
│   └── kernel.config       # Configuration .config du noyau du périphérique (5.4.161-perf)
├── scripts/
│   ├── ghostlock_all.sh    # Script de test en masse
│   └── ghostlock_check.sh  # Script de détection
├── src/
│   ├── ghostlock64.c       # PoC original à double erase 8-iov (structure de base)
│   ├── ghostlock5-33.c     # Versions d'itération précoce (ghostlock5 ~ ghostlock33)
│   ├── ghostlock63.c       # Variante 3-iov ghostlock 6.x
│   ├── g62_*.c             # Variantes 3-iov (différentes adresses cibles)
│   ├── g62_8e.c            # Spray 8-iov précis (version finale)
│   ├── g62_scan.c          # Scan de décalage iov multiple
│   ├── g62_self.c          # Test de déclenchement EDEADLK auto du waiter
│   ├── g62_pispray.c       # Test EDEADLK + slab spray + sched_setattr
│   ├── g62_rand.c          # Test d'écriture de randomize_va_space
│   ├── gsu_v19.c           # Déclenchement 8-iov + sched_setattr
│   ├── gl_pselect*.c       # Test pselect + sched_setattr
│   ├── gl_scan.c           # Scan de décalage fd_set
│   ├── sc64.c              # Payload shellcode
│   ├── trigger*.c          # PoC de déclenchement original (vérification de la vulnérabilité)
│   ├── ghostlock_root.c    # Tentative de root précoce
│   └── test_*.c            # Tests de compilation/exécution
├── README.md
├── ghostlock64             # Binaire du PoC double erase 8-iov
├── ghostlock63             # Binaire ghostlock 6.x 3-iov
├── g62_*                   # Binaires des variantes 3-iov
├── gl_*                    # Binaires des tests pselect
├── gsu                     # Variante de détournement sc-page
├── sc64                    # Shellcode
├── trigger*                # Binaires des PoC de déclenchement originaux
└── test_*                  # Binaires de test

Conclusion

L'implémentation de la chaîne PI de cette version du noyau (5.4.161 ARM32) ne supporte pas la technique d'écriture arbitraire double rb_erase de GhostLock. Toutes les routes d'exploitation connues de CVE-2026-43499 sont bloquées sur ce périphérique. Il est nécessaire de découvrir une nouvelle primitive d'écriture de zéro ou une autre vulnérabilité pour continuer.

Mot de l'auteur

Huawei, tu m'as tué, tu m'as coûté 30 RMB de tokens DeepSeek V4 Pro.