Project Zero ottiene root su Pixel 10 con exploit 0-click e driver Tensor G5

Project Zero rivela una nuova catena di exploit zero-click capace di ottenere privilegi root su Pixel 10 combinando una variante aggiornata della vulnerabilità Dolby UDC con un bug logico nel driver VPU del chip Tensor G5. La ricerca mostra come un vettore remoto senza interazione dell’utente possa partire dalla decodifica video e arrivare al controllo della memoria kernel attraverso il mapping arbitrario di memoria fisica. In parallelo Amazon Web Services pubblica bulletin di sicurezza su Fragnesia, identificata come CVE-2026-46300, e sulle varianti DirtyFrag o copy.fail del kernel Linux, confermando aggiornamenti per Amazon Linux, EKS, ECS, SageMaker, Fargate e altri servizi cloud. Le due vicende collegano il rischio mobile flagship e quello cloud infrastructure: da un lato i driver Android espongono primitive kernel critiche, dall’altro i moduli Linux consentono privilege escalation locale in ambienti enterprise. Il caso Pixel 10 prosegue una linea già emersa quando Project Zero aveva mostrato come una catena 0-click su Pixel 9 potesse partire da un allegato audio e arrivare al kernel Android, confermando che codec, driver e funzionalità multimediali restano una superficie d’attacco decisiva.

Project Zero dimostra una chain 0-click per ottenere root su Pixel 10

Project Zero descrive una catena di exploit che compromette Pixel 10 senza alcuna interazione dell’utente e porta fino all’accesso root completo. Il ricercatore Seth Jenkins aggiorna un exploit Dolby UDC già utilizzato nella ricerca su Pixel 9 e lo combina con una nuova vulnerabilità nel driver VPU del chip Tensor G5. L’attacco sfrutta il componente di decoding video basato sul silicio Chips&Media Wave677DV, raggiungendo prima il contesto mediacodec e poi il kernel attraverso una primitiva di lettura e scrittura fisica. La catena funziona sui dispositivi Pixel 10 non aggiornati, in particolare con SPL dicembre 2025 o precedente, perché la patch per il bug Dolby era già disponibile ma non ancora applicata a tutti gli ambienti vulnerabili. Google riceve il report sul bug VPU il 24 novembre 2025 e lo corregge nel bollettino Android di febbraio 2026, con un tempo di triage di 71 giorni. Il dettaglio è rilevante perché mostra un miglioramento rispetto a casi precedenti, ma conferma anche quanto sia breve la distanza tra un bug driver apparentemente circoscritto e una compromissione completa del dispositivo.

Il driver VPU del Tensor G5 espone memoria fisica allo userspace

Il punto tecnico più grave riguarda il driver VPU del Tensor G5, che espone interfacce MMIO direttamente allo userspace e presenta un difetto nella funzione vpu_mmap. Il driver non limita la dimensione della VMA alla reale regione dei registri MMIO e usa remap_pfn_range basandosi sulla dimensione richiesta dal processo. Questo permette a un processo nel dominio mediacodec SELinux di mappare memoria fisica arbitraria partendo dall’indirizzo fisico dei registri VPU. Poiché l’immagine del kernel si trova a un indirizzo fisico più alto rispetto alla regione VPU e sui Pixel non è protetta da KASLR fisico, l’attaccante ottiene accesso in lettura e scrittura alla memoria kernel con pochissime istruzioni. Project Zero sottolinea che bastano circa cinque righe di codice per trasformare l’errore di boundary checking in una primitiva di compromissione estremamente potente. Il driver gestisce mappature, power management e interrupt handling, ma interfaccia direttamente l’hardware Wave677DV senza passare dal framework V4L2, aumentando il rischio di esposizione diretta. Questo schema richiama il caso BigWave, perché VPU e BigWave derivano dallo stesso perimetro di sviluppo e mostrano pattern simili di validazione insufficiente.

Dolby UDC resta il primo anello della compromissione zero-click

La prima fase della catena nasce da una variante aggiornata dell’exploit Dolby UDC, già osservato nella ricerca su Pixel 9 e adattato agli offset specifici del Pixel 10. La vulnerabilità iniziale consente di ottenere esecuzione nel contesto del decodificatore multimediale, sfruttando il fatto che contenuti audio o video possono essere processati automaticamente senza un click esplicito dell’utente. Sul nuovo dispositivo il sistema RET PAC impedisce alcune tecniche usate in precedenza, tra cui l’abuso di __stack_chk_fail, costringendo il ricercatore a modificare la strategia di exploit. L’attacco sovrascrive quindi dap_cdp_init, funzione chiamata una sola volta durante l’inizializzazione del decoder, ottenendo un punto di controllo compatibile con le mitigazioni del Pixel 10. Questo passaggio mostra come le protezioni moderne non eliminino il rischio, ma spostino il costo dell’exploit verso tecniche più specifiche e più aderenti al ciclo di vita del componente vulnerabile. Il valore della ricerca sta proprio nella dimostrazione della concatenazione: un bug multimediale porta al contesto mediacodec, mentre il driver VPU consente l’uscita verso il kernel. In questa prospettiva i nuovi premi del programma Google VRP per exploit zero-click su Pixel e Titan confermano quanto siano preziose le catene complete contro dispositivi aggiornati.

Il bug VPU evidenzia rischi strutturali nei driver Android

La vulnerabilità del driver VPU non è soltanto un errore isolato, ma un segnale strutturale sui rischi dei driver Android che espongono hardware complesso a processi sandboxati ma raggiungibili da vettori remoti. Il contesto mediacodec dovrebbe contenere l’impatto dei bug nei parser multimediali, ma diventa molto più pericoloso quando può interagire con driver potenti e poco vincolati. Jann Horn collabora a un audit di circa due ore e identifica rapidamente il difetto, elemento che suggerisce una carenza di review di base su controlli dimensionali e boundary checking. Android VRP classifica la vulnerabilità come High severity, un miglioramento rispetto a bug analoghi precedentemente valutati in modo più conservativo. Tuttavia la catena dimostra che un bug High può diventare critico quando viene combinato con un primo stadio zero-click. L’assenza di KASLR fisico sui Pixel rende inoltre più prevedibili gli indirizzi kernel e riduce la complessità dell’exploit. Google corregge il problema nel bollettino di febbraio 2026, ma Project Zero insiste sulla necessità di audit proattivi, riduzione dell’accesso ai driver, seccomp più restrittivo per mediacodec e sviluppo security-aware nei componenti hardware-facing.

Fragnesia consente privilege escalation locale nei kernel Linux

Mentre Project Zero documenta la compromissione del Pixel 10, AWS pubblica aggiornamenti su Fragnesia, vulnerabilità CVE-2026-46300 collegata alla classe DirtyFrag o copy.fail nel kernel Linux. La falla consente a un utente locale non privilegiato di ottenere privilegi root attraverso il modulo espintcp, sfruttando una corruzione deterministica della page cache di file read-only. Il proof-of-concept pubblico mostra come l’attaccante possa alterare il comportamento di file protetti senza modificarli direttamente sul disco, trasformando un accesso locale limitato in compromissione completa dell’host. AWS comunica che Amazon Linux non risulta impattato da Fragnesia perché non fornisce il modulo espintcp, ma applica comunque una patch di correctness al core networking come difesa in profondità. La decisione è significativa perché riconosce il rischio di issue simili in altre implementazioni di protocolli di rete e riduce la probabilità di varianti future. Fragnesia si aggiunge alle vulnerabilità CVE-2026-43284 e CVE-2026-31431, già ricondotte alla famiglia DirtyFrag/copy.fail e associate a moduli come xfrm_user, esp4, esp6 e algif_aead. Il tema era già emerso quando Dirty Frag aveva esposto ambienti AWS e moduli IPSec a privilege escalation locale su kernel Linux.

AWS aggiorna Amazon Linux e servizi cloud gestiti

AWS avvia una timeline di patching articolata per ridurre l’esposizione di kernel Linux e servizi gestiti. Amazon Linux riceve aggiornamenti per le linee kernel 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 e 6.18, coprendo una parte molto ampia dell’infrastruttura cloud in produzione. I clienti devono applicare gli update disponibili e riavviare le istanze dove necessario. Bottlerocket, ECS Optimized AMIs ed EKS Optimized AMIs ricevono immagini aggiornate entro il 19 maggio 2026, mentre EMR prevede update entro il 26 maggio 2026 con un primo rilascio per CVE-2026-31431 entro il 20 maggio. Fargate distribuisce platform version patchate in tutte le regioni entro il 25 maggio 2026, con aggiornamenti dedicati per Fargate 1.3 e 1.4 rispettivamente entro il 19 e il 15 maggio. Le AWS Deep Learning AMIs aggiornate per Neuron Base, Trainium e Inferentia risultano già disponibili. L’approccio di AWS conferma che le vulnerabilità kernel non sono un problema limitato alle singole istanze EC2, ma coinvolgono immagini, piattaforme gestite, orchestratori container, ambienti ML e servizi serverless.

SageMaker, Fargate ed EKS richiedono riavvii e nuove immagini

Per gli utenti SageMaker, AWS applica kernel patchati automaticamente alle risorse create o riavviate dopo specifiche date di metà maggio 2026, ma alcune azioni restano a carico dei clienti. Notebook, app Studio, app Canvas e cluster HyperPod devono essere riavviati o aggiornati per ricevere il kernel corretto. I job di Training, Processing e Batch Transform lanciati dopo le date di cutoff usano automaticamente immagini patchate, mentre workload persistenti o già in esecuzione possono richiedere interventi manuali. Per EKS ed ECS, gli amministratori devono lanciare nuove istanze basate sulle AMI aggiornate o forzare il riciclo dei nodi vulnerabili. Le istanze Fargate e alcune ECS Managed Instances ricevono piattaforme aggiornate senza azioni dirette una volta completato il rollout regionale, ma il monitoraggio della versione resta essenziale. La complessità della risposta mostra quanto il patching cloud sia diverso dal patching server tradizionale: non basta aggiornare un pacchetto, bisogna verificare immagini, nodi, runtime, orchestratori e servizi gestiti. Nei contesti AI e ML, questo diventa ancora più critico perché l’infrastruttura cloud moderna combina GPU, acceleratori, container e servizi gestiti in catene operative difficili da aggiornare in modo uniforme.

Pixel 10 e AWS mostrano lo stesso problema di fiducia nel kernel

La catena Pixel 10 e i bulletin AWS sembrano scenari diversi, ma condividono lo stesso nucleo tecnico: un componente apparentemente periferico può diventare una strada verso privilegi totali. Nel Pixel 10 il percorso passa da Dolby UDC al driver VPU e poi alla memoria kernel; in AWS e Linux il percorso passa da moduli networking e page cache fino a root. In entrambi i casi, l’attaccante non ha bisogno di rompere l’intero sistema: deve trovare una singola interfaccia esposta, poco vincolata o mal validata, e usarla per scavalcare i confini di sicurezza. Questo è il punto centrale per dispositivi mobile e cloud enterprise. Le sandbox, SELinux, container, user namespaces e servizi gestiti riducono l’impatto degli exploit solo se i driver e i moduli kernel rispettano confini rigorosi. Quando un driver consente mapping fisico arbitrario o un modulo networking permette corruzione deterministica della page cache, il modello di isolamento perde rapidamente efficacia. Per questo Project Zero insiste su audit proattivi dei driver Android, mentre AWS applica patch di correctness anche su componenti non direttamente impattati da Fragnesia.

Utenti Pixel e amministratori AWS devono applicare subito gli aggiornamenti

Le azioni richieste sono immediate. Gli utenti Pixel 10 devono installare il bollettino di sicurezza Android di febbraio 2026 o versioni successive, soprattutto se il dispositivo era fermo a SPL dicembre 2025 o precedente. Gli amministratori AWS devono verificare le versioni kernel in uso, applicare gli update di Amazon Linux, aggiornare AMI EKS ed ECS, riavviare risorse SageMaker persistenti e controllare lo stato delle platform version Fargate. Per Fragnesia, AWS chiarisce che Amazon Linux non include il modulo espintcp vulnerabile, ma l’hardening al core networking va comunque installato per ridurre rischi futuri. Per DirtyFrag/copy.fail, invece, il patching resta prioritario perché i moduli coinvolti sono diffusi e presenti in numerosi ambienti cloud. La lezione comune è netta: nel 2026 la sicurezza non dipende solo dalla presenza di patch, ma dalla velocità con cui vengono effettivamente applicate su dispositivi, immagini, nodi e workload. Project Zero e AWS mostrano due lati dello stesso problema: exploit chain mobile e privilege escalation cloud nascono spesso da bug superficiali nei componenti più profondi del sistema.