Informazioni sulla vulnerabilità

CVE-2026-31431, pubblicamente nota come Copy Fail, è una vulnerabilità di escalation dei privilegi locali nel kernel Linux associata al modulo algif_aead, che implementa l'interfaccia AEAD dell'API crittografica del kernel in spazio utente tramite AF_ALG.

In termini pratici, il problema consente a un utente locale con privilegi ridotti di abusare di un difetto logico nel percorso di gestione della memoria di questo sottosistema e di elevare l'impatto fino al compromesso completo dell'integrità del sistema. Il punteggio pubblicato da kernel.org e riportato nel NVD è CVSS 7.8, con vettore AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, il che significa che l'attacco richiede esecuzione locale ma ha un impatto elevato su riservatezza, integrità e disponibilità.

Quando è stata introdotta e divulgata

• La causa principale sfruttabile è stata introdotta nel kernel nel 2017, quando è stata aggiunta un'ottimizzazione in-place a algif_aead.
• La CVE è stata pubblicata nel NVD il 22 aprile 2026.
• La divulgazione pubblica più ampia del problema, sotto il nome Copy Fail e con un proof of concept pubblico, è avvenuta il 29 aprile 2026.
• La correzione principale a monte è stata committata il 1 aprile 2026, prima della divulgazione pubblica agli utenti finali.

Cosa sfrutta

Secondo gli advisory tecnici pubblicati, il difetto si basa sulla combinazione di:

• l'interfaccia AF_ALG del kernel
• il modulo algif_aead
• un'ottimizzazione delle operazioni in-place introdotta nel 2017
• il concatenamento di questa interfaccia con splice()

Il risultato pratico è la capacità di un processo locale di eseguire una piccola scrittura controllata nelle pagine supportate dalla page cache di file leggibili. In condizioni favorevoli, ciò è sufficiente per trasformare un limitato punto d'appoggio locale in un'escalation dei privilegi a root.

Come questo influisce sull'azienda

Il rischio reale non è semplicemente "eseguire un kernel Linux vulnerabile", ma consentire al codice locale a bassa fiducia di raggiungere questo percorso del kernel. Negli ambienti aziendali, ciò di solito significa una maggiore esposizione su:

• server multiutente
• host di salto e bastion
• runner CI/CD
• carichi di lavoro containerizzati che eseguono codice non fidato
• cluster Kubernetes
• VM che ospitano automazione, agenti, plugin o job di terze parti

Se un attaccante dispone già di una qualche forma di esecuzione locale, anche senza root, questa CVE può diventare il passo successivo verso il compromesso dell'host. In pratica, ciò amplia il rischio di:

• compromissione completa del server
• modifica di binari o artefatti locali
• furto di credenziali, token e segreti residenti
• movimento laterale verso altre risorse
• sabotaggio di pipeline e catene di build

A cosa serve il modulo algif_aead

algif_aead fa parte dell'interfaccia crittografica del kernel in spazio utente (AF_ALG). Consente alle applicazioni di utilizzare primitive crittografiche del kernel tramite socket, in particolare operazioni AEAD (Authenticated Encryption with Associated Data).

Questo modulo di solito non è essenziale per la maggior parte dei carichi di lavoro server standard. Secondo le linee guida di mitigazione pubblicate da CERT-EU, disabilitare algif_aead come mitigazione temporanea:

• non dovrebbe influire su dm-crypt o LUKS
• non dovrebbe influire su kTLS
• non dovrebbe influire su IPsec/XFRM
• non dovrebbe influire su OpenSSL, GnuTLS, NSS o SSH nell'uso standard

D'altro canto, disabilitarlo potrebbe influire su:

• applicazioni configurate esplicitamente per utilizzare il motore afalg
• software che apre socket AF_ALG direttamente
• integrazioni personalizzate che utilizzano aead, skcipher o hash tramite l'API crittografica del kernel

In altre parole, per la maggior parte degli host aziendali, bloccare il modulo tende ad avere un impatto ridotto. In appliance, stack crittografici personalizzati o percorsi software fortemente ottimizzati, l'impatto dovrebbe essere validato prima del rollout.

Impatto operativo della disabilitazione del modulo

Bloccare il modulo riduce immediatamente l'esposizione, ma comporta dei compromessi:

• le applicazioni che dipendono da AF_ALG potrebbero non avviarsi o perdere l'accelerazione crittografica supportata dal kernel
• i carichi di lavoro personalizzati potrebbero fallire solo a runtime, non all'avvio
• se il modulo è già caricato, la mitigazione è completa solo dopo uno scaricamento riuscito o un riavvio

Per gli ambienti di produzione, l'approccio più sicuro è applicare la mitigazione in una finestra di manutenzione controllata e validare successivamente le applicazioni critiche.

Correzione permanente consigliata

La blacklist del modulo è solo una mitigazione temporanea. La correzione permanente è:

1. installare un kernel patchato fornito dal vendor della distribuzione
2. riavviare l'host in modo che il nuovo kernel venga effettivamente caricato
3. validare che l'host non risulti più segnalato come affetto
4. solo allora decidere se la blacklist del modulo debba rimanere in vigore

Misure aggiuntive consigliate:

• dare priorità alla patch sugli host con utenti locali, container o esecuzione di codice non fidato
• limitare la creazione di socket AF_ALG con seccomp in container e pipeline dove applicabile
• verificare dove afalg o l'API crittografica del kernel sono utilizzati esplicitamente
• mantenere un inventario delle versioni del kernel e dei riavvii pendenti
• trattare i runner CI/CD e i nodi Kubernetes come priorità alta

Cosa controlla lo script

Lo script ispeziona:

• hostname dell'host
• versione del kernel in esecuzione
• sistema operativo tramite /etc/os-release
• presenza del modulo algif_aead
• se il modulo è attualmente caricato
• se il modulo è bloccato da una regola modprobe
• se l'host richiede un riavvio (/var/run/reboot-required)
• stato segnalato da Ubuntu Pro tramite pro fix CVE-2026-31431 --dry-run, quando disponibile

In base a ciò, restituisce una delle seguenti classificazioni:

• PATCHED_OR_NOT_AFFECTED
• LIKELY_NOT_VULNERABLE
• MITIGATED
• VULNERABLE_MODULE_LOADED
• POTENTIALLY_VULNERABLE
• UNKNOWN

Logica di classificazione

In sintesi:

• Se gli strumenti Ubuntu indicano che l'host non è affetto o è già corretto, lo stato diventa PATCHED_OR_NOT_AFFECTED.
• Se il modulo algif_aead non esiste nel kernel corrente, lo stato tende a essere LIKELY_NOT_VULNERABLE.
• Se il modulo esiste ma è bloccato e non caricato, lo stato diventa MITIGATED.
• Se Ubuntu indica che l'host è affetto e il modulo è caricato, lo stato diventa VULNERABLE_MODULE_LOADED.
• Se il modulo esiste ed è caricabile ma lo stato della patch non può essere confermato, lo stato diventa POTENTIALLY_VULNERABLE.

Requisiti

• Bash
• modinfo
• modprobe
• lsmod
• awk
• grep
• hostname
• uname
• apt-get per --update
• sudo quando si esegue come utente non root
• pro opzionalmente, per arricchire l'analisi su Ubuntu

Utilizzo

Se il file dello script si chiama check_cve_2026_31431.sh:

Controllo predefinito

Esempio di output:

Output JSON

Esempio:

Questo output è utile per automazione, inventario delle risorse e pipeline di conformità.

Mitigazione

La modalità --mitigate crea il file:

Con il seguente contenuto:

Successivamente, lo script tenta di rimuovere il modulo dalla memoria con:

Utilizzo:

Se l'utente non è root, lo script tenterà di utilizzare sudo.

Aggiornamento

La modalità --update esegue:

Utilizzo:

Questa modalità tenta di aggiornare i pacchetti relativi al kernel su sistemi basati su Debian e Ubuntu. In altri ambienti, questo passaggio potrebbe non essere applicabile.

Aiuto

Output:

Limitazioni importanti

• Lo script utilizza euristiche. Non dimostra lo sfruttamento; stima l'esposizione e lo stato di mitigazione.
• I campi ubuntu_affected e fix_available dipendono dalla presenza del comando pro.
• Il passaggio --update utilizza pattern di pacchetti orientati a Ubuntu e Debian e potrebbe non coprire tutti i kernel personalizzati.
• Su alcune distribuzioni, il modulo potrebbe esistere con un comportamento diverso da quello previsto dallo script.
• Il blocco del modulo potrebbe richiedere un riavvio in alcuni ambienti per garantire uno stato coerente.

Flusso di lavoro consigliato

1. Eseguire --check per valutare l'host.
2. Se il modulo è disponibile e nessuna patch è applicata, eseguire --mitigate.
3. Eseguire --update o applicare l'aggiornamento ufficiale del vendor.
4. Riavviare l'host se richiesto.
5. Eseguire --check --json per validare lo stato finale e conservare le prove.

Nota

Per chiarezza di pubblicazione, lo script dovrebbe idealmente utilizzare un nome descrittivo come:

Crediti

Materiale organizzato e pubblicato con credito a SEC17.

Sito web ufficiale:

• https://sec17.com