CVE-2026-43499 · Honor WIN RT (AAK-AN00) Note di ricerca sul Root temporaneo

（È tutto scritto da deepseek, io non ci capisco niente） （Ho smanettato ancora per qualche giorno, progressi zero, ho rinunciato） （Al momento è possibile ottenere il root, ma è molto instabile, dopo il root si perde la rete, scollegando il cavo si riavvia） （Tutte le conclusioni di questo repository valgono solo per Honor WIN RT, vulnerabilità CVE-2026-43499, kernel 6.6.118-android15-8-gf17133276a57-abogki518694926-4k, non estendere le conclusioni al root temporaneo, il root temporaneo può durare e funzionare in modo relativamente stabile）

Bootloader del dispositivo bloccato permanentemente (ro.oem_unlock.supported vuoto), niente fastboot, niente su persistente, niente Magisk. L'unica strada ancora percorribile è la vulnerabilità del kernel. Questo repository documenta l'intero processo da "si può fare?" a "quanto è stabile dopo averlo fatto".

Natura: root temporaneo, si perde al riavvio.

---

Disclaimer

Questo repository documenta un processo di ricerca sulla sicurezza condotto su un dispositivo di mia proprietà, con l'obiettivo di comprendere le cause e i limiti di stabilità di una race condition PI del kernel.

• Non contiene alcun binario exploit né payload di sfruttamento direttamente eseguibile —— payload e framework provengono da progetti pubblici upstream, questo repository si limita a citarli, non a ridistribuirli.
• Non fornisce tutorial su metodi di bypass per alcun produttore specifico, e non incoraggia l'uso su dispositivi non autorizzati.
• Gli offset e gli indirizzi dei simboli presenti nel repository sono validi solo per l'unica build del kernel elencata in questo documento, cambiando kernel diventano tutti invalidi.
• I difetti correlati sono già stati corretti upstream (vedi sotto). Il valore a lungo termine di questo documento risiede in "questo resoconto stesso" —— un'autentica analisi retrospettiva di una vulnerabilità di race condition in condizioni reali e non ideali, inclusi tutti i suoi effetti collaterali scomodi.

---

0. Conclusione in una frase

L'unico percorso portato a termine è:

CVE-2026-43499（race condition futex PI write-what-where） + carrier rt_sigreturn
  → iniezione LD_PRELOAD in un processo del dominio shell
  → in due fasi: prima si porta SELinux in Permissive, poi si modifica task->real_cred / cred in init_cred
  → uid=0(root) context=u:r:kernel:s0, e si impianta il demone su

Ma ciò che vale davvero la pena di scrivere non è "come ottenere il root" —— è ciò che accade dopo averlo ottenuto.

Ciò che si ottiene non è un root stabile, ma uno "stato che può esplodere in qualsiasi momento".

La primitiva di scrittura dell'exploit inserisce un rt_mutex_waiter falsificato nella catena futex PI reale, e il vettore di questo waiter è uno stack del kernel / pagina spruzzata che verrà riutilizzata dalle successive chiamate di sistema. Quindi dal momento in cui il root atterra, qualsiasi cambiamento di scheduling o priorità a livello di sistema può calpestarlo, causando direttamente un kernel panic e un riavvio. Questo non è un bug, è il costo intrinseco di questa tecnica di sfruttamento —— vedi docs/03.

---

1. Limiti di applicabilità (in caso di difformità l'intera soluzione è invalida)

Voce	Valore	Note
Modello	Honor WIN RT, modello AAK-AN00	Nome commerciale "Honor WIN RT"
SoC	Snapdragon 8 Elite SM8750-AB	Con Honor WIN (AAP-AN00, SM8850-AC) il firmware non è intercambiabile
Sistema	Android 16 / MagicOS 10	—
Kernel	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ Condizione obbligatoria, corrispondenza carattere per carattere
Configurazione kernel	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	Premessa della geometria del carrier
Pacchetto firmware	.170	.160 / .175 non testati
Bootloader	Bloccato permanentemente	Niente fastboot / niente su persistente

Perché è indispensabile fissare la versione del kernel: il difetto è stato corretto in 6.6.140, questa macchina ha 6.6.118 < 6.6.140 quindi è ancora presente; inoltre tutti gli indirizzi dei simboli del kernel dell'exploit e la "geometria del carrier" sono ancorati a questa singola build, cambiando kernel la tabella degli offset diventa immediatamente invalida, e in genere non è possibile tornare indietro.

---

2. Panoramica del percorso di privilege escalation

┌─ Materiali ────────────────────────────────────────────┐
│ boot.img + xbl_config.elf（estratti dal firmware del dispositivo）│
│        ↓ risoluzione dei simboli                        │
│ target.h（indirizzi dei simboli del kernel, verificati byte per byte con kallsyms）│
│        ↓ build                                          │
│ preload.so ──► lato dispositivo /data/local/tmp/*.so    │
└────────────────────────────────────────────────────────┘
                 ↓  iniezione LD_PRELOAD
     ┌──────────── in due fasi（necessariamente due processi separati）────────────┐
     │ Fase A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Fase B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred（eseguito dal processo "scrittore preimpostato"）│
     │         → setresuid(0,0,0) normalizzazione                  │
     │         → impianto su incorporato + daemon                  │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Tre punti che devono essere eseguiti correttamente (sbagliando si rimane bloccati o si va direttamente in panic):

1. Regola ferrea dell'ordine: prima real_cred, poi cred. In ordine inverso si ottengono immediatamente pieni privilegi e i thread vanno fuori controllo.
2. Tra i due colpi esiste inevitabilmente uno stato transitorio con cred ≠ real_cred. In quel momento qualsiasi sched_setaffinity restituisce EPERM → l'intero ciclo si blocca. La soluzione corretta è fare fork del processo "scrittore preimpostato" prima del primo colpo (credenziali pulite), il processo padre esegue il primo colpo, lo scrittore esegue il secondo, nessuno dei due effettua syscall nello stato transitorio.
3. Il modello degli indirizzi è indipendente da KASLR. L'intero sfruttamento passa solo attraverso l'alias della mappatura lineare alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), stabile tra i riavvii; il vero valore della cosiddetta "fase slide" è l'autoverifica della primitiva di scrittura, non il bypass di KASLR.

Framework upstream: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Attenzione, questo non è GhostLock —— GhostLock segue la via pselect, che non corrisponde alla geometria del punto di atterraggio del waiter di questa build, vedi docs/06.

---

3. Indice