CVE-2026-31431 (Copy Fail): cosa comporta per i dispositivi Linux embedded – e cosa fare ora

Il 29 aprile 2026, Theori ha reso nota la vulnerabilità CVE-2026-31431 (“Copy Fail”), una vulnerabilità di escalation dei privilegi nel kernel di Linux algif_aead interfaccia crypto, accessibile tramite socket AF_ALG. La vulnerabilità riguarda le principali distribuzioni Linux che utilizzano versioni del kernel vulnerabili introdotte nel 2017.

L'exploit richiede un accesso locale, ma il suo comportamento deterministico e la sua capacità di aggirare i sistemi di monitoraggio dell'integrità dei file lo rendono particolarmente rilevante per i sistemi embedded, in particolare quelli che utilizzano container o distribuzioni Linux generiche.

Questo articolo illustra quali sono le sue caratteristiche distintive, dove risiede il vero rischio per gli OEM del settore embedded e come affrontarlo.

In breve

• Tipo: Escalation dei privilegi locali (LPE)
• CVE: CVE-2026-31431 (CVSS 7,8)
• Riguarda: I kernel Linux a partire dal 2017 con CONFIG_CRYPTO_USER_API_AEAD abilitato
• Vulnerabilità: deterministica, nessuna condizione di competizione, PoC pubblico disponibile (script Python da 732 byte; la primitiva del kernel è indipendente dal linguaggio)
• Ambito: tra container tramite cache di pagina condivisa
• Risoluzione: patch del kernel disponibile nel ramo stabile e nei backport dei fornitori

Cosa rende "Copy Fail" diverso dagli altri

Il kernel Linux ha già presentato in passato bug di escalation dei privilegi di grande rilevanza. Dirty Cow (2016) richiedeva una condizione di competizione e spesso causava il crash dei sistemi. Dirty Pipe (2022) era specifico per determinate versioni. Copy Fail rappresenta invece un problema di natura diversa.

È deterministico. Non ci sono condizioni di competizione da sfruttare, né finestre temporali, né offset specifici del kernel. Lo stesso exploit, senza alcuna modifica, consente di ottenere i privilegi di root su Ubuntu, Amazon Linux, RHEL e SUSE – su tutte le principali distribuzioni testate – senza richiedere condizioni temporali o di competizione. Ciò elimina una delle principali difese naturali nell'ambito dello sfruttamento del kernel: l'imprevedibilità.

È invisibile agli strumenti di integrità convenzionali. L'exploit modifica la cache delle pagine in memoria di un binario setuid, non il file sul disco. Il monitoraggio standard dell'integrità dei file, che verifica i checksum a livello di disco, non rileva nulla. Il binario sul disco rimane integro. Tuttavia, quando il kernel lo carica, viene eseguita la versione danneggiata presente in memoria, con privilegi di root.

E supera i confini dei container. La cache della pagina è condivisa tra tutti i processi su un host, compresi i container. Un container compromesso può danneggiare i file binari visibili agli altri container e al kernel dell'host. Per le architetture che si basano sull'isolamento basato sui container – compresi i progetti a criticità mista utilizzati nei sistemi medici e industriali – ciò rappresenta una via di fuga concreta dai container.

La causa tecnica alla radice

La vulnerabilità risiede nel kernel algif_aead modulo crittografico. Il problema deriva da una gestione non sicura delle scatterlist supportate dalla cache di pagina durante le operazioni AEAD in loco, che consente di ottenere riferimenti scrivibili a pagine supportate da file altrimenti di sola lettura. Un commit di ottimizzazione del 2017 ha introdotto questa gestione delle operazioni in loco, violando un presupposto di sicurezza fondamentale.

L'exploit sfrutta le vulnerabilità del kernel AF_ALG interfaccia crittografica (che consente agli utenti senza privilegi di eseguire la crittografia con accelerazione hardware) con splice() (che passa le pagine della cache per riferimento anziché copiarle). Il risultato è una scrittura controllata di 4 byte nella cache di pagina di qualsiasi file leggibile. Scegliere un binario setuid adatto come /usr/bin/su e ottieni i privilegi di root.

AF_ALG è abilitato praticamente in tutte le configurazioni standard del kernel. Non sono richiesti privilegi speciali né moduli aggiuntivi.

Dove il rischio è reale e dove non lo è

"Copy Fail" è un'escalation dei privilegi locali. L'autore dell'attacco deve già disporre di accesso locale come utente senza privilegi.

Per la maggior parte dei dispositivi embedded – strumenti medici monouso, controllori industriali, sistemi con configurazione bloccata – non esistono account utente senza privilegi, né shell interattive, né alcun modo per eseguire uno script Python senza prima violare un perimetro separato. In tali implementazioni, la vulnerabilità diretta è bassa.

Anche i sistemi che applicano politiche rigorose di SELinux o AppArmor potrebbero presentare un rischio ridotto. Sui dispositivi Android/AOSP in cui SELinux è correttamente implementato, l'interfaccia socket AF_ALG non è in genere accessibile ai processi senza privilegi: la divulgazione di Theori ha confermato che i dispositivi con una profonda integrazione di SELinux non sono vulnerabili attraverso questa via. Ciò è rilevante per qualsiasi sistema embedded – basato su Android o meno – in cui le politiche di controllo obbligatorio degli accessi limitano l'accesso alle interfacce crittografiche del kernel.

Questo non significa che puoi ignorarlo. Ci sono tre scenari da tenere in considerazione:

Architetture basate su container. Se il dispositivo esegue più carichi di lavoro in container su un kernel condiviso – una configurazione sempre più diffusa nei dispositivi medici che integrano funzioni legacy in moderni SoC – Copy Fail compromette il modello di isolamento. Un container dell'applicazione compromesso può sfuggire al controllo dell'host.

In combinazione con una vulnerabilità di rete. Il "Copy Fail" diventa grave se associato a una falla che consente l'esecuzione di codice da remoto. Un aggressore che ottiene l'accesso iniziale tramite un bug dell'interfaccia web, un'API esposta o un canale di aggiornamento compromesso può quindi elevare i propri privilegi a root in un istante. È la catena di vulnerabilità a fare la differenza.

Conformità normativa. Anche se la vulnerabilità non è praticamente sfruttabile nella vostra configurazione, un CVE pubblico accompagnato da un proof-of-concept funzionante comporta obblighi di documentazione e valutazione ai sensi delle linee guida post-commercializzazione della FDA, del regolamento MDR dell'UE e della norma IEC 62443. I vostri team addetti alla qualità e alla conformità normativa devono valutare e documentare la vostra esposizione. Questo aspetto non è facoltativo.

Non è una questione di distribuzione. È una questione di configurazione del kernel.

C'è un malinteso diffuso secondo cui si tratterebbe di un "problema di distribuzione" e che passare da Ubuntu a Yocto consentirebbe di evitarlo. Non è proprio così. CVE-2026-31431 è un bug del kernel. Qualsiasi build che utilizzi versioni del kernel vulnerabili (introdotte nel 2017) contiene il codice interessato, indipendentemente dal fatto che sia stata assemblata da Canonical, Red Hat o dalla propria pipeline Yocto.

Ma la vulnerabilità ha importanza solo se CONFIG_CRYPTO_USER_API_AEAD è abilitato. È il modulo che rende AF_ALG accessibile allo spazio utente e rende possibile l'exploit.

Le distribuzioni generiche – Ubuntu, RHEL, Debian, SUSE – lo abilitano di default. Non hanno altra scelta. Sono pensate per una vasta gamma di scenari d'uso e non possono prevedere le esigenze dell'utente finale. Includono tutto, compresa la superficie di attacco.

Yocto e Buildroot, con configurazioni del kernel predefinite o generiche, si trovano nella stessa situazione. Una build Yocto non è automaticamente più sicura di Ubuntu. Dipende dalle scelte effettuate durante la configurazione.

Un kernel integrato opportunamente ottimizzato – in cui ogni modulo è valutato in base alle effettive esigenze del dispositivo – probabilmente non consente CONFIG_CRYPTO_USER_API_AEAD. Non c'è alcun motivo per cui un display chirurgico o un controller industriale debbano avere accesso allo spazio utente ai socket crittografici del kernel. La stessa logica vale per i binari setuid e gli account utente senza privilegi: in una configurazione minimale, nessuno di questi dovrebbe esistere. (Nota: il proof-of-concept pubblicato utilizza Python, ma la primitiva del kernel sottostante può essere attivata da qualsiasi binario compilato. La semplice assenza di Python non costituisce una misura di mitigazione sufficiente.)

La vulnerabilità risiede nel kernel. La possibilità di sfruttarla dipende dalle scelte effettuate a livello di configurazione del sistema operativo. Gli OEM che hanno effettuato scelte di configurazione del kernel deliberate e informate dal punto di vista della sicurezza potrebbero aver ridotto l'esposizione, a seconda della loro configurazione specifica. Coloro che hanno distribuito una distribuzione generica – o una build Yocto con impostazioni predefinite – dovrebbero verificare.

Perché continua a succedere

Copy Fail non è il primo CVE critico del kernel, e non sarà l'ultimo. Dirty Cow risale al 2016. Dirty Pipe al 2022. Il modello si ripete ogni pochi anni e la sfida da affrontare è sempre la stessa: valutare l'impatto, creare un'immagine patchata, convalidarla, distribuirla ai dispositivi sul campo e documentare tutto per l'autorità di regolamentazione. Gli strumenti che hanno portato alla luce Copy Fail – l'analisi del codice assistita dall'intelligenza artificiale – ne individueranno altri. Il tasso di scoperta sta per accelerare.

Ci sono due cose che vale la pena dire chiaramente:

L'aggiornamento non è la parte difficile. Lo è invece la sua implementazione. Ubuntu e RHEL hanno risolto il problema nel giro di pochi giorni. Tuttavia, per i dispositivi embedded presenti in ospedali, fabbriche e veicoli, l'applicazione di tale patch richiede un'infrastruttura OTA, la visibilità della flotta, il controllo delle modifiche normative e una nuova convalida. Molti OEM che utilizzano distribuzioni generiche non dispongono di tale processo. E l'esecuzione apt-get update L'installazione su un dispositivo soggetto a regolamentazione comporta una serie incontrollata di modifiche ai pacchetti, senza tracciabilità, senza test di compatibilità con la vostra applicazione e senza possibilità di ripristino. In un ambiente regolamentato, questa non è una correzione, ma una violazione della conformità.

Attenzione agli strumenti. Non sono loro a decidere. Gli scanner CVE e gli strumenti SBOM segnaleranno l'errore "Copy Fail" nel giro di poche ore. Tuttavia, non valutano se CONFIG_CRYPTO_USER_API_AEAD è addirittura abilitata nella vostra build. Non valutano se la vulnerabilità sia accessibile su un dispositivo privo di utenti senza privilegi. Non forniscono la valutazione dell'impatto specifica per il dispositivo, la decisione sulla correzione né la documentazione relativa al controllo delle modifiche richiesta dal vostro fascicolo tecnico. Il divario tra un avviso sul dashboard e una correzione convalidata e documentata è proprio il punto in cui la maggior parte degli OEM perde tempo.

Entrambi i problemi derivano dalla stessa causa principale: considerare il sistema operativo come una scelta di integrazione una tantum anziché come una dipendenza gestita con un ciclo di vita pluriennale. Un kernel minimale che abilitasse solo le funzionalità necessarie al dispositivo non avrebbe esposto algif_aead innanzitutto. Un percorso di aggiornamento ben definito e un impegno di manutenzione a lungo termine consentirebbero di colmare il divario di implementazione quando verrà pubblicato il prossimo CVE.

Misure consigliate per gli OEM

Se state sviluppando o gestendo prodotti embedded basati su Linux, ecco cosa vi consigliamo.

1. Controlla innanzitutto la configurazione del kernel. Prima di dare per scontato di essere vulnerabile, verifica se CONFIG_CRYPTO_USER_API_AEAD è abilitato:

zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API_AEAD

Se /proc/config.gz se non è disponibile sul tuo sistema di destinazione (cosa comune nelle build embedded minimaliste), controlla invece il tuo sistema di compilazione: verifica il .config oppure defconfig nella directory dei sorgenti del kernel, esegui grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r) nelle distribuzioni che lo memorizzano in quella posizione, oppure in Yocto controlla direttamente il file `defconfig` della ricetta del kernel.

Se restituisce not set oppure non è presente, il percorso dell'exploit noto non è raggiungibile sul tuo dispositivo. Si tratta di una fase iniziale fondamentale di valutazione.

2. Effettuate un inventario delle versioni del kernel. Verificate quali kernel sono in esecuzione nelle vostre linee di prodotti e nel parco macchine implementato. Sono interessate le versioni del kernel a partire dal 2017 che includono il percorso di codice vulnerabile e hanno il modulo abilitato.

3. Applicare la patch dell'upstream. Effettuare l'aggiornamento alle build del kernel che includono la correzione. Le versioni con la patch sono disponibili nel ramo stabile di Linux e tramite backport specifici dei fornitori.

4. Adotta misure di mitigazione prima di applicare le patch. Se non è possibile aggiornare immediatamente il kernel, disattivare il algif_aead modulo, limitare l'accesso al socket AF_ALG tramite seccomp e applicare le politiche SELinux o AppArmor per limitare quali processi possono accedere all'interfaccia del socket crittografico.

5. Rivalutare i presupposti relativi all'isolamento dei container. Se la vostra architettura utilizza i container per l'isolamento dei carichi di lavoro su un kernel condiviso, questa vulnerabilità dimostra chiaramente che non è possibile fare affidamento esclusivamente sui container come barriera di sicurezza. Valutate se il vostro modello di minaccia richieda un livello di isolamento a livello hardware o di hypervisor.

6. Aggiornate la vostra SBOM e i registri delle vulnerabilità. Documentate la vulnerabilità CVE-2026-31431 nella vostra SBOM e nelle valutazioni dei rischi per la sicurezza informatica. Per i dispositivi regolamentati dalla FDA, ciò va a integrare il vostro piano di gestione della sicurezza informatica post-commercializzazione. Per quanto riguarda il regolamento MDR dell'UE, ciò potrebbe comportare una valutazione di vigilanza.

7. Pianificate l'aggiornamento sul campo. Per i dispositivi già installati, stabilite la procedura di aggiornamento. Se disponete della funzionalità OTA, datele la priorità. In caso contrario, questo è il momento di pensare a come gestirete la prossima vulnerabilità critica del kernel (CVE), perché ce ne sarà sicuramente una.

8. Comunicate con i vostri clienti. Informate i vostri clienti a valle e gli utenti clinici in merito alla vulnerabilità, alla vostra valutazione e alle tempistiche previste. La trasparenza crea fiducia.

Il segnale più ampio

Un'ultima cosa degna di nota. Il bug "Copy Fail" è stato individuato grazie a una revisione del codice assistita dall'intelligenza artificiale. Un ricercatore ha applicato uno strumento di analisi automatizzata al sottosistema crittografico del kernel, che ha individuato la falla in circa un'ora. Un errore logico rimasto nascosto per nove anni.

La situazione sta cambiando per gli OEM del settore embedded. Il ritmo con cui vengono scoperte gravi vulnerabilità del kernel è destinato ad aumentare. La domanda non è se il vostro sistema operativo presenti vulnerabilità – perché le presenta. La domanda è se il vostro processo di sviluppo, la vostra infrastruttura di aggiornamento e la vostra documentazione normativa siano in grado di stare al passo con questi ritmi.

Dichiarazione di non responsabilità: il presente articolo è fornito esclusivamente a scopo informativo e non costituisce una consulenza legale, normativa o in materia di sicurezza informatica. Le informazioni riportate riflettono osservazioni generali relative a una vulnerabilità resa pubblica e potrebbero non essere applicabili a specifiche configurazioni di dispositivi o ambienti di implementazione. I clienti e gli OEM sono responsabili di valutare l'applicabilità, l'impatto e le misure correttive all'interno dei propri sistemi, compresa la conformità ai requisiti normativi applicabili. L4B Software non garantisce che le informazioni fornite siano complete o sufficienti per alcun uso specifico.