Copy Fail: il bug Linux da 732 byte che dormiva nel kernel dal…

Un utente locale non privilegiato ottiene root in modo deterministico. L'exploit pesa 732 byte. Il bug era nel kernel dal 2017. Questo è CVE-2026-31431, battezzato

Un utente locale non privilegiato ottiene root in modo deterministico. L'exploit pesa 732 byte. Il bug era nel kernel dal 2017. Questo è CVE-2026-31431, battezzato "Copy Fail" dai ricercatori di Xint.io e Theori, che l'hanno reso pubblico il 29 aprile 2026.

Punti chiave

CVE-2026-31431 ha CVSS 7.8 (HIGH): accesso locale, bassa complessità, impatto completo su riservatezza, integrità e disponibilità.
L'exploit di 732 byte scrive 4 byte controllati nella page cache in memoria, senza alterare i file su disco.
Il bug risiede nel modulo algif_aead dal 2017; il fix è il commit a664bf3d603d del 1° aprile 2026.
Distribuzioni verificate vulnerabili: Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, SUSE 16, Rocky Linux 9.7.

Tre commit, una primitiva di scrittura arbitraria

La vulnerabilità è un bug di interazione tra tre modifiche al kernel. Nel 2017 uno sviluppatore introdusse un'ottimizzazione in-place in algif_aead.c che permetteva al sottosistema crittografico AF_ALG di riutilizzare buffer di input come output. Nel 2023 un secondo sviluppatore modificò il modo in cui splice() gestisce i riferimenti alle pagine. Nel 2024 un terzo ottimizzò il percorso di scrittura nella page cache. Nessuna modifica era singolarmente difettosa.

La concatenazione crea una condizione in cui pagine della page cache — normalmente di sola lettura per i processi non privilegiati — finiscono in una scatterlist di destinazione scrivibile durante operazioni AEAD. Un processo apre un socket AF_ALG, lo collega con splice() a un file leggibile, e ottiene una primitiva di scrittura di 4 byte in posizioni arbitrarie della page cache.

Secondo i ricercatori di Xint.io, citati da The Hacker News: «Un utente locale non privilegiato può scrivere quattro byte controllati nella page cache di qualsiasi file leggibile su un sistema Linux, e usare questo per ottenere i privilegi di root».

La corruzione avviene esclusivamente in memoria. Il kernel non segna la pagina corrotta come dirty, quindi non viene mai flushed su disco. Il file originale resta intatto, ma i processi che lo leggono — inclusi quelli con bit setuid — eseguono il codice modificato. Questo meccanismo è documentato da Kaspersky SecureList e da TurboLab.it.

"This vulnerability is unique because it has four properties that almost never appear together: it's portable, tiny, stealthy, and cross-container" — Portavoce Xint.io, via The Hacker News

La page cache condivisa e il rischio di container escape

I container condividono il kernel con l'host. La page cache sfugge all'isolamento dei namespace: è un'unica struttura dati globale del kernel, condivisa tra tutti i processi del sistema. Un container con accesso non privilegiato a un file leggibile dall'host può corromperne la page cache.

Kaspersky SecureList ha documentato il rischio per ambienti multi-tenant: Docker, LXC e Kubernetes sono interessati perché l'attacco non richiede capability aggiuntive. Secondo i ricercatori di Theori, citati da TurboLab.it: «Concatenalo con qualsiasi cosa ti permetta di ottenerlo — una RCE web che atterra in un account di servizio non privilegiato, un punto d'appoggio SSH, una PR malevola su un runner CI — e sei root».

L'exploit funziona in modo deterministico, senza race condition. David Brumley di Bugcrowd ha collocato Copy Fail in una classe di fragilità ricorrente: «Copy Fail è la stessa classe di primitiva, in un sottosistema diverso».

Patch e distribuzioni confermate

Il commit di fix a664bf3d603d è stato inserito nel ramo principale del kernel Linux il 1° aprile 2026. Il record CVE-2026-31431, pubblicato da CVE.org, conferma il punteggio CVSS 7.8 con vettore AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H e identifica sia il commit vulnerabile che quello di correzione. CERT-EU ha emesso un advisory con priorità alta.

HelpNetSecurity ha verificato lo stato di distribuzione al 30 aprile 2026. Le distribuzioni confermate vulnerabili includono Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, SUSE 16 e Rocky Linux 9.7. Ubuntu 26.04 e kernel successivi non sono affetti. CISA ha inserito CVE-2026-31431 nel catalogo Known Exploited Vulnerabilities con scadenza al 15 maggio 2026 per le agenzie federali statunitensi.

Il tracker di sicurezza di Arch Linux ha pubblicato le versioni affected/fixed per la propria distribuzione. Sono emerse varianti dell'exploit in Go e Rust, documentate da Kaspersky SecureList.

Cosa fare adesso

Le mitigazioni documentate nelle fonti primarie sono tre. Primo: applicare il patch del kernel non appena disponibile dalla propria distribuzione. Secondo: dove applicabile, disabilitare il modulo algif_aead se non necessario per operazioni crittografiche; CERT-EU conferma che questa disabilitazione non compromette dm-crypt/LUKS, IPsec, OpenSSL o SSH. Terzo: monitorare le varianti dell'exploit in Go e Rust riportate da Kaspersky SecureList.

Il numero esatto di sistemi compromessi in natura non è noto. Nonostante la convergenza delle fonti tecniche, il brief non documenta exploitation in-the-wild al di fuori delle varianti PoC pubblicate. La fonte non specifica l'efficacia delle regole di rilevamento Kaspersky sulle varianti non Python.

Perché è importante

Otto anni di dormienza per un bug che richiede solo accesso locale e un interprete Python. La deterministicità dell'exploit — nessuna race condition, nessun timing dipendente dall'hardware — lo rende riproducibile. Le dimensioni, 732 byte, lo rendono trasportabile. L'assenza di tracce su disco lo rende furtivo rispetto alle verifiche di integrità file-based.

La classe di primitiva — corruzione della page cache come vector di privilege escalation — non è nuova, come nota Brumley. La novità è la confluenza di proprietà in un singolo sottosistema accessibile da utente non privilegiato. Il modulo algif_aead, progettato per operazioni crittografiche accelerate, si rivela un punto di ingresso per scrittura arbitraria in memoria.

La fonte non specifica perché la vulnerabilità sia rimasta dormiente per otto anni, né il contributo specifico dello strumento AI Xint Code rispetto all'intuizione umana di Taeyang Lee nella scoperta.

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

Fonti

Fonti e riferimenti