// 1 CRITICAL · 1 ZERO-DAY · 4 CVE · 3 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
Ricercatori di SSD Secure Disclosure hanno dimostrato una catena di exploit su chip Unisoc che dal modem raggiunge il kernel Android via chiamata video VoLTE

Il 17 agosto 2026 SSD Secure Disclosure ha pubblicato l'advisory di una catena di exploit in due stadi che partendo dal firmware modem di chipset Unisoc raggiunge il kernel Android con privilegi completi. La vulnerabilità, classificata come CWE-1189 per isolamento improprio delle risorse su System-on-a-Chip, interessa chip T606, T612 e T7250 montati su dispositivi aggiornati fino a gennaio 2026. Nessun identificatore CVE è stato assegnato e Unisoc non ha risposto alle segnalazioni di marzo e di agosto.

Punti chiave
  • La catena di exploit richiede una chiamata video VoLTE su rete 4G controllata dall'attaccante per ottenere RCE nel firmware modem
  • Dal contesto modem i ricercatori hanno disabilitato l'ARM MPU via registri coprocessore, mappando l'intero spazio indirizzi fisici a 32 bit in lettura, scrittura ed esecuzione
  • Dispositivi confermati vulnerabili: Motorola E13, Realme C33 e Xiaomi Redmi A5 con patch Android rispettivamente di febbraio 2025, luglio 2025 e gennaio 2026
  • Unisoc non ha risposto per cinque mesi alle segnalazioni via email e LinkedIn; l'Android Security Bulletin di agosto 2026 non include alcuna mitigazione

Il meccanismo: quando il modem e il processore applicativo condividono la memoria fisica

Il problema architetturale è nella memoria fisica condivisa tra modem processor e application processor all'interno del SoC Unisoc, senza confine imposto dall'hardware che impedisca al codice in esecuzione nel contesto modem di modificare la memoria del kernel. Secondo l'advisory di SSD Secure Disclosure, citato da The Hacker News, l'unica barriera è l'ARM Memory Protection Unit, configurabile proprio dal lato modem.

Nella seconda fase dell'exploit, i ricercatori hanno scritto una configurazione di accesso totale all'MPU tramite istruzioni MCR p15, operando sui registri coprocessore che governano i domini di memoria. Il risultato è la mappatura dell'intero spazio di indirizzamento fisico a 32 bit come RWX — leggibile, scrivibile ed eseguibile — dal contesto modem.

TechTimes e Dark Reading hanno fornito dettagli aggiuntivi. Dark Reading ha descritto frammenti di shellcode da 0x4b0 byte pre-caricati nell'heap del modem, con un meccanismo egg-hunter che ricompone il payload nella memoria fisica. TechTimes ha indicato l'indirizzo fisico 0x80080000 come quello in cui risiede il kernel Android sui dispositivi testati.

Da SIP/SDP al printk: la catena confermata in laboratorio

La prima fase, sviluppata a marzo 2026, sfrutta messaggi SIP/SDP malformati nella negoziazione della chiamata video VoLTE per ottenere esecuzione remota nel firmware modem. La seconda fase, pubblicata ad agosto, eleva i privilegi dal modem al kernel Android.

I ricercatori hanno confermato l'esecuzione a livello kernel osservando l'output di printk nei log del kernel, secondo quanto riportato da The Hacker News. Il proof-of-concept ha impiegato un core 4G Open5GS, una radio SDR LimeSDR e SIM card Osmocom per simulare l'infrastruttura di rete. La fonte non specifica che la stessa catena funzioni su reti cellulari commerciali senza modifiche.

"La condizione che rende possibile tutto questo è uno spazio di memoria fisica condiviso tra il processore modem e il processore applicativo all'interno del SoC Unisoc, senza alcun confine imposto dall'hardware che impedisca al codice in contesto modem di modificare la memoria del kernel" — SSD Secure Disclosure, via The Hacker News

Il vuoto di accountability: patch Android che non toccano il modem

La struttura del problema espone un'incoerenza nel modello di sicurezza Android. Gli aggiornamenti mensili del sistema operativo distribuiti da Google e dagli OEM non includono il firmware modem, che è proprietà del vendor del chipset e viene aggiornato — se mai — su canali separati e spesso invisibili all'utente.

Come osserva TechTimes, "un telefono aggiornato con le patch Android più recenti potrebbe eseguire un firmware modem che non è mai stato aggiornato". Il precedente di CVE-2022-20210, una vulnerabilità modem Unisoc che il vendor aveva corretto e distribuito tramite Android Security Bulletin, dimostra la capacità tecnica di rispondere. La scelta di non farlo nei due casi attuali è deliberata, non una limitazione tecnica.

Unisoc detiene circa il 14% della quota globale di smartphone SoC nel primo semestre 2026, secondo Counterpoint Research. I chip alimentano dispositivi venduti in oltre 140 paesi dai marchi Motorola, Realme, Xiaomi, Samsung, Honor, vivo, Nokia e ZTE. Non tutti i dispositivi di questi brand sono confermati vulnerabili: il dossier documenta esplicitamente solo Motorola E13, Realme C33 e Xiaomi Redmi A5.

La conferma indipendente: Kaspersky e la stessa falla in altri contesti

Nel novembre 2025 Kaspersky ICS CERT aveva documentato autonomamente la medesima condizione architetturale su un SoC Unisoc UIS7862A montato su unità head unit per veicoli. Anche in quel caso, modem e processore applicativo condividevano la memoria fisica senza isolamento hardware; i ricercatori avevano raggiunto l'accesso kernel tramite una periferica DMA nascosta.

La ricerca di Kaspersky non è direttamente collegata alla catena VoLTE pubblicata da SSD Secure Disclosure, ma corrobora il pattern: la mancanza di isolamento non è un difetto limitato a un singolo chipset o a un singolo percorso di attacco, ma una scelta progettuale con ripercussioni su più linee di prodotto.

Cosa fare adesso

La mancanza di patch lascia gli OEM e gli utenti senza leve operative dirette: il firmware modem non è aggiornabile dai canali Android standard. Questa condizione strutturale, documentata nel brief, impedisce qualsiasi mitigazione autonoma da parte dell'utente finale o dell'amministratore di sistema.

Il firmware modem resta sotto il controllo esclusivo del vendor del chipset. Gli aggiornamenti Android distribuiti mensilmente non interessano questo componente, che riceve patch — quando le riceve — tramite processi opachi e spesso inaccessibili. Il caso CVE-2022-20210 dimostra che Unisoc è tecnicamente in grado di patchare, ma il silenzio di cinque mesi sulle segnalazioni attuali indica una scelta di non intervento.

Per gli utenti, la fonte non specifica alcuna contromisura efficace oltre alla consapevolezza del rischio architetturale. La catena è confermata solo su rete 4G controllata, non su reti commerciali, ma la natura del bug — accesso RWX alla memoria fisica del kernel — rende l'impatto massimo in caso di replicazione su infrastrutture pubbliche.

Perché è importante

Il caso Unisoc mette in luce un gap di governance nella supply chain mobile. Google controlla il sistema operativo, gli OEM assemblano i dispositivi, ma il firmware del modem — componente con privilegi pari o superiori al kernel — resta una zona grigia senza oversight effettivo. L'Android Security Bulletin di agosto 2026 non include alcuna voce per questa vulnerabilità, e nessun bollettino Unisoc la menziona.

Il precedente CVE-2022-20210 mostra che il vendor sapeva già come gestire questa classe di bug. Il silenzio attuale, documentato dalle stesse fonti che hanno verificato la catena di exploit, non è attribuibile a incompetenza tecnica. È una scelta di non risposta in un settore dove la frammentazione della responsabilità — tra chipset vendor, OEM e gestore del sistema operativo — lascia gli utenti finali senza interlocutore.

La quota di mercato del 14% di Unisoc, concentrata nel segmento sotto i 150 dollari, significa che i dispositivi più vulnerabili sono quelli con minor accesso a supporto tecnico e sostituzione rapida. La fonte non specifica il numero esatto di dispositivi esposti, ma la combinazione di accesso kernel confermato, assenza di patch e silenzio del vendor definisce un profilo di rischio elevato per la durata del ciclo di vita residuo di questi prodotti.

Le informazioni sono basate sull'advisory SSD Secure Disclosure e sulle analisi tecniche derivate.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. cwe.mitre.org
  2. thehackernews.com
  3. infosecurity-magazine.com
  4. darkreading.com
  5. techtimes.com
  6. ics-cert.kaspersky.com
  7. thomasharris6.wordpress.com
  8. news.cybertechworld.co.in
  9. secnews.gr