Galaxy S25 Ultra, exploit kernel abilita il root su due varianti

🛡️ Executive Summary

• CVE-2026-43499 colpisce rtmutex nel kernel Linux e consente a un’app locale di costruire una escalation di privilegi.
• Root My Galaxy installa KernelSU senza sbloccare il bootloader, ma soltanto su profili firmware Samsung verificati e perfettamente corrispondenti.
• Aggiornare resta la mitigazione principale: il feed pubblico supporta due Galaxy S25 Ultra e non include Galaxy Z Fold 7.

Un nuovo strumento chiamato Root My Galaxy sfrutta la vulnerabilità CVE-2026-43499 per ottenere privilegi root su alcuni smartphone Samsung Galaxy senza seguire il tradizionale percorso basato sullo sblocco del bootloader. Il progetto installa KernelSU attraverso un exploit locale del kernel Linux e automatizza la selezione del payload in base alla versione esatta del firmware. La compatibilità è però molto più limitata rispetto alle descrizioni circolate online: il feed pubblico documenta attualmente due sole varianti del Galaxy S25 Ultra, mentre non contiene profili funzionanti per Galaxy Z Fold 7. Il metodo dimostra comunque che la chiusura del bootloader introdotta con One UI 8 non elimina le possibilità di compromissione del kernel.

Root My Galaxy funziona solo su firmware Samsung specifici

Root My Galaxy viene presentato come un installer di KernelSU utilizzabile con un solo comando dall’interfaccia dell’applicazione, senza modificare manualmente l’immagine di avvio e senza ricorrere alle procedure tradizionali basate su Odin. Il progetto separa il codice dell’app Android dai profili dei dispositivi, dagli offset del kernel, dai payload nativi dell’exploit e dai componenti KernelSU. L’app confronta automaticamente il valore completo di kernelRelease, l’identificativo della build, la versione SDK, l’architettura ABI e la dimensione delle pagine di memoria, rifiutando l’installazione quando anche uno solo di questi elementi non coincide.

Il feed pubblico attuale contiene due profili verificati sul dispositivo: Galaxy S25 Ultra SM-S938N, destinato al mercato sudcoreano, con firmware S938NKSUACZF1, e Galaxy S25 Ultra SM-S9380, commercializzato in alcuni mercati asiatici, con firmware S9380ZHUBCZF1. Entrambi utilizzano un kernel Samsung basato sulla linea Android 15 6.6 e richiedono esattamente la build indicata. È presente anche un profilo per Galaxy S24 Ultra SM-S928U e SM-S928U1, ma lo stato riportato è ancora “hardware debugging in progress” e non “device-tested”. Il repository specifica espressamente che un modello identico con una build differente non deve essere considerato compatibile e richiede un porting separato. La precisazione è rilevante perché la notizia è stata associata anche al Galaxy Z Fold 7, dispositivo sul quale Samsung ha distribuito la patch di sicurezza di luglio insieme alla serie Galaxy S25. Nel file targets-v2.json pubblicamente utilizzato dall’applicazione, tuttavia, non compare alcun modello della serie Fold. La disponibilità dell’exploit per una determinata versione del kernel non significa quindi che esista già un payload operativo per qualsiasi smartphone che utilizzi la stessa generazione di Android.

CVE-2026-43499 trasforma un bug rtmutex in privilegi root

La vulnerabilità sfruttata da Root My Galaxy si trova nel sottosistema rtmutex del kernel Linux e riguarda la funzione remove_waiter(). Durante il rollback di un proxy lock attivato attraverso rt_mutex_start_proxy_lock() e futex_requeue(), la funzione opera sul task corrente invece che sul task realmente associato al waiter. Questa incongruenza può lasciare un puntatore pendente nella struttura pi_blocked_on, eseguire operazioni sull’albero red-black senza il corretto lock e intervenire sulla catena di priorità del processo sbagliato. Il risultato è una condizione use-after-free sfruttabile localmente per alterare la memoria del kernel.

Il vettore è locale: CVE-2026-43499 non permette da sola un attacco remoto o zero-click. Un aggressore deve prima riuscire a eseguire codice sul dispositivo, ad esempio convincendo l’utente a installare un’applicazione malevola. Una volta avviato il payload, però, la separazione tra una normale app Android e il kernel può essere superata, trasformando un’applicazione priva di privilegi amministrativi in codice con controllo quasi completo del sistema. È proprio questo passaggio a rendere la falla importante anche fuori dall’ambiente del modding. Il codice pubblico dell’exploit crea più thread che coordinano operazioni FUTEX_WAIT_REQUEUE_PI, FUTEX_CMP_REQUEUE_PI e modifiche della priorità per provocare la condizione di memoria vulnerabile. La catena tenta successivamente di individuare la base del kernel nonostante KASLR, predisporre primitive di lettura e scrittura sulla memoria fisica attraverso buffer pipe e modificare le credenziali del processo. Il codice registra esplicitamente i cambiamenti di UID, GID, contesto di sicurezza e stato di SELinux, mostrando che l’obiettivo non è un semplice crash, ma una vera escalation a root. Il caso conferma quanto il kernel Linux determini direttamente la sicurezza degli smartphone Android. Le protezioni applicative, i permessi e il sandboxing restano fondamentali, ma diventano insufficienti quando un bug nel kernel consente al codice locale di costruire primitive affidabili di lettura e scrittura sulla memoria privilegiata.

Il bootloader resta bloccato ma Knox non è una garanzia assoluta

L’interesse intorno al progetto nasce anche dalla rimozione dell’opzione OEM Unlocking osservata sui dispositivi aggiornati a One UI 8, compresi Galaxy S25 e i pieghevoli Galaxy Z Fold 7 e Z Flip 7. La modifica impedisce il percorso tradizionale utilizzato per installare recovery personalizzate, kernel modificati e custom ROM, rafforzando una strategia che combina Android 16 con le protezioni di Samsung Knox e la crittografia post-quantum introdotta in One UI 8.

Root My Galaxy aggira il problema senza sbloccare formalmente il bootloader. Il payload sfrutta il kernel già in esecuzione e carica una build KernelSU late-load, evitando di sostituire in modo permanente il boot image firmato da Samsung. Questo approccio può impedire l’attivazione del tradizionale contatore hardware Knox Warranty Void, normalmente associato al flashing di componenti non autorizzati, ma non significa che il dispositivo conservi automaticamente tutte le proprie garanzie di sicurezza. Il root permette infatti di intervenire su processi, file, configurazioni e controlli che operano sopra la componente hardware. Knox Vault continua a proteggere chiavi e segreti all’interno del proprio ambiente isolato, descritto nell’analisi sull’integrazione tra silicio Samsung, NPU e Knox Vault, ma un sistema operativo compromesso può comunque esporre dati, intercettare input, alterare applicazioni o aggirare controlli software. Il mancato intervento sul fuse non deve quindi essere confuso con l’assenza di rischi. Poiché il caricamento avviene sul kernel attivo e non modifica stabilmente la catena di avvio, il root deve inoltre essere considerato legato alla sessione e alla specifica build supportata. Un riavvio, un aggiornamento OTA o una variazione del kernel possono rendere necessario un nuovo sfruttamento o impedire completamente il funzionamento del payload.

Aggiornamenti e distribuzione dei payload restano i punti critici

La mitigazione principale consiste nell’installare gli aggiornamenti Samsung più recenti e nel non eseguire APK provenienti da fonti non controllate. Il record della vulnerabilità indica che il problema è stato corretto nelle versioni stabili del kernel Linux, compresa la linea 6.6.140, mentre i profili pubblicati da Root My Galaxy utilizzano build Samsung basate su 6.6.98. Il confronto numerico non è però sufficiente per stabilire se uno smartphone sia protetto, perché i produttori possono applicare singoli backport di sicurezza senza aggiornare l’intera versione del kernel.

Il bollettino Samsung di luglio non elenca esplicitamente CVE-2026-43499, mentre il feed dello strumento continua a indicare build CZF1 specifiche. Non è quindi corretto affermare in modo generalizzato che qualsiasi Galaxy S25, Fold 7 o dispositivo con Android 16 sia vulnerabile, né che una determinata patch mensile abbia certamente chiuso l’exploit senza una verifica sul firmware concreto. Esiste inoltre un elemento di fiducia nella catena di distribuzione. L’app risolve prima il commit corrente del repository dei payload e scarica i file da quel riferimento immutabile, riducendo il rischio che gli artefatti cambino durante la procedura. Lo schema pubblico, però, non include firme del manifest o hash SHA-256 per ogni payload. La release v0.2.3, pubblicata il 19 luglio 2026, ha rimosso la verifica della firma del manifest per facilitare i contributi della comunità. Chi utilizza lo strumento affida quindi l’esecuzione di codice con accesso al kernel al repository, all’account del manutentore e all’infrastruttura GitHub. Per la ricerca di sicurezza questo modello facilita porting e sperimentazione, ma per un utente comune amplia sensibilmente il rischio operativo. La stessa tecnica che consente a un proprietario di recuperare il controllo del proprio dispositivo può essere incorporata in un’app malevola per sottrarre quel controllo senza autorizzazione.