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

(scritto interamente da deepseek, io non capisco nulla)

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

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, senza ridistribuirli.
• Non fornisce tutorial su metodi di bypass per alcun produttore specifico, né incoraggia l'uso su dispositivi non autorizzati.
• Gli offset e gli indirizzi dei simboli presenti nel repository sono validi solo per l'unico build del kernel elencato in questo documento; cambiando kernel diventano tutti invalidi.
• I difetti in questione sono già stati corretti upstream (vedi sotto). Il valore a lungo termine di questo documento risiede in "questa documentazione stessa" — un resoconto reale di una vulnerabilità di race condition in condizioni non ideali, inclusi tutti i suoi effetti collaterali scomodi.

0. Conclusione in una riga

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 portare SELinux in Permissive, poi modificare task->real_cred / cred in init_cred
  → uid=0(root) context=u:r:kernel:s0, e installazione del daemon su

Ma ciò che vale davvero la pena scrivere non è "come ottenere 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 spray che verrà riutilizzata dalle successive system call. Pertanto, dal momento in cui root atterra, qualsiasi cambiamento di scheduling o priorità a livello di sistema può calpestarlo, causando direttamente un kernel panic e un riavvio. Non è un bug, è il costo intrinseco di questa tecnica di sfruttamento — vedi docs/03.

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

Perché è indispensabile vincolare la versione del kernel: il difetto è stato corretto in 6.6.140, e 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 questo singolo 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 ──► /data/local/tmp/*.so sul dispositivo    │
└────────────────────────────────────────────────────────┘
                 ↓  iniezione LD_PRELOAD
     ┌──────────── in due fasi (richiede due processi distinti) ────────────┐
     │ 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                  │
     │         → installazione del su incorporato + daemon         │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Tre punti che devono essere eseguiti correttamente (in caso contrario si blocca o si va direttamente in panic):

1. Regola ferrea dell'ordine: prima real_cred, poi cred. L'ordine inverso causa un'immediata escalation completa dei privilegi e la perdita di controllo dei thread.
2. Tra i due colpi esiste inevitabilmente uno stato transitorio in cui cred ≠ real_cred. In quel momento qualsiasi sched_setaffinity restituisce EPERM → l'intero ciclo si blocca. La soluzione corretta è effettuare il fork del processo "scrittore preimpostato" prima del primo colpo (credenziali pulite): il processo padre esegue il primo colpo, lo scrittore esegue il secondo, e nessuno dei due effettua syscall nello stato transitorio.
3. Il modello degli indirizzi è indipendente da KASLR. L'intero sfruttamento utilizza solo l'alias della mappatura lineare alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), stabile tra i riavvii; il vero valore della cosiddetta "fase di 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 di pselect, che non corrisponde alla geometria del punto di atterraggio del waiter di questo build, vedi docs/06.

3. Indice

4. Cronologia

5. Una riga per chi verrà dopo

Se anche tu stai attaccando un modello con BL bloccato, pensa prima chiaramente a cosa vuoi fare con root, perché su questi modelli root è molto probabilmente una finestra utilizzabile solo per una decina di minuti. Elenca le operazioni che "richiedono root e devono sopravvivere al riavvio", eseguile tutte in una volta, poi reboot per tornare a uno stato pulito. Non cercare di "eliminare gli effetti collaterali" — è il costo intrinseco della tecnica stessa.