CVE-2026-31431 «Copy Fail»: vulnerabilità del kernel Linux

Shared FAQ page chrome (breadcrumb, dates, read time, «Continua a leggere», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Sintesi

È stata divulgata pubblicamente una vulnerabilità di escalation locale dei privilegi ad alto impatto nel kernel Linux, CVE-2026-31431, nota anche come «Copy Fail».

La vulnerabilità riguarda l'interfaccia crittografica del kernel Linux, in particolare il percorso algif_aead / AF_ALG. Sulle versioni del kernel interessate, un utente locale senza privilegi può riuscire a ottenere i privilegi di root. I ricercatori che l'hanno scoperta descrivono il problema come presente nelle principali distribuzioni Linux con kernel compilati dal 2017 in poi, con un rischio particolare per i server multiutente, le piattaforme container, i runner CI/CD e gli ambienti multi-tenant.

Il problema è tracciato come CVE-2026-31431. Ubuntu lo classifica High con CVSS 7.8, mentre Red Hat ne valuta l'impatto come Important.

EuroVPS raccomanda vivamente che tutti i server Linux interessati vengano verificati e aggiornati non appena i kernel corretti o le mitigazioni dei produttori siano disponibili.

---

Che cos'è CVE-2026-31431?

CVE-2026-31431 è una vulnerabilità del kernel Linux nel sottosistema crypto. Il difetto riguarda un'operazione in-place errata in algif_aead, dove le mappature di origine e di destinazione differiscono. La correzione upstream del kernel è associata al commit mainline a664bf3d603d, che annulla l'ottimizzazione problematica del 2017.

La vulnerabilità non è di per sé una vulnerabilità di rete remota. Tuttavia, se un attaccante ha già un accesso shell locale, l'accesso tramite un'applicazione web compromessa, l'esecuzione in un container o un altro punto d'appoggio, la vulnerabilità può consentire l'escalation ai pieni privilegi di root.

---

Sistemi operativi interessati e correzioni / patch dei produttori

La vulnerabilità può interessare molte distribuzioni Linux con kernel compilati dal 2017 in poi. Lo stato varia per distribuzione e per kernel stream, quindi l'azione corretta è seguire l'avviso ufficiale del produttore del vostro sistema operativo.

1. AlmaLinux

AlmaLinux ha rilasciato kernel corretti per le versioni supportate. Le versioni corrette confermate sono:

Sistema operativo	Versione del kernel corretta
AlmaLinux 8	kernel-4.18.0-553.121.1.el8_10 o successiva
AlmaLinux 9	kernel-5.14.0-611.49.2.el9_7 o successiva
AlmaLinux 10	kernel-6.12.0-124.52.2.el10_1 o successiva
AlmaLinux Kitten 10	kernel-6.12.0-225.el10 o successiva

Aggiornamento consigliato:

sudo dnf clean all
sudo dnf upgrade 'kernel*'
sudo reboot

Verifica dopo il riavvio:

uname -r
rpm -q kernel

2. Oracle Linux

Anche Oracle Linux è interessato quando esegue build vulnerabili del kernel Linux. Oracle ha rilasciato aggiornamenti di sicurezza Unbreakable Enterprise Kernel (UEK) per CVE-2026-31431 tramite errata ufficiali di Oracle Linux.

Versione Oracle Linux / kernel stream	Kernel corretto / livello di patch
Oracle Linux 7 / 8, UEK R6	kernel-uek-5.4.17-2136.354.4.2.el7uek / el8uek o successiva
Oracle Linux 8 / 9, UEK R7	kernel-uek-5.15.0-319.201.4.4.el8uek / el9uek o successiva
Oracle Linux 9 / 10, UEK R8	kernel-uek-6.12.0-201.74.2.2.el9uek / el10uek o successiva

Oracle classifica gli aggiornamenti UEK come SECURITY, IMPORTANT, rilasciati il 2026-05-01, e include CVE-2026-31431 nelle correzioni crypto del kernel.

Aggiornamento consigliato:

sudo dnf clean all
sudo dnf update 'kernel*'
sudo reboot

Per i sistemi Oracle Linux più vecchi che usano yum:

yum clean all
yum update 'kernel*'
reboot

Verifica Oracle Linux

cat /etc/oracle-release
uname -r
rpm -q kernel-uek
rpm -q kernel kernel-core

Assicuratevi che il kernel in esecuzione mostrato da uname -r sia il kernel corretto, non semplicemente installato.

3. CloudLinux

CloudLinux conferma che CL7 non è interessato, mentre CL7h, CL8, CL9 e CL10 sono interessati. CL7h e CL8 vengono corretti tramite kernel CloudLinux, mentre CL9 e CL10 usano gli aggiornamenti del kernel di AlmaLinux.

Le versioni di destinazione confermate da CloudLinux includono:

Sistema operativo	Versione del kernel corretta
CloudLinux 7	Non interessato
CloudLinux 7 Hybrid / CL7h	kernel-4.18.0-553.121.1.lve.el7h.x86_64 o successiva
CloudLinux 8	kernel-4.18.0-553.121.1.lve.el8.x86_64 o successiva
CloudLinux 9	kernel-5.14.0-611.49.2.el9_7 o successiva
CloudLinux 10	kernel-6.12.0-124.52.2.el10_1 o successiva

Aggiornamento consigliato per CloudLinux 8 / 9 / 10:

sudo dnf clean metadata
sudo dnf upgrade 'kernel*'
sudo reboot

Per i sistemi CloudLinux più vecchi che usano yum:

yum update 'kernel*'
reboot

Verifica:

uname -r
rpm -q kernel

Per i sistemi con KernelCare:

kcarectl --update
kcarectl --info | grep CVE-2026-31431

CloudLinux dichiara che le live patch KernelCare per molte distribuzioni interessate, inclusi gli stream AlmaLinux, CloudLinux, Red Hat, Rocky, Oracle Linux, Ubuntu e Debian, sono state rilasciate nel feed principale a partire dal 2 maggio 2026.

---

4. Ubuntu

Ubuntu ha pubblicato sia una voce nel CVE tracker sia un post dedicato sul proprio blog. Ubuntu dichiara che la mitigazione viene distribuita tramite il pacchetto kmod e che la correzione della vulnerabilità sarà distribuita tramite i pacchetti Linux kernel image.

Aggiornamento consigliato:

sudo apt update
sudo apt upgrade
sudo reboot

Per applicare solo il pacchetto di mitigazione, dove applicabile:

sudo apt update
sudo apt install --only-upgrade kmod
sudo reboot

Verifica:

uname -r
dpkg -l 'linux-image*' | grep ^ii
dpkg -l kmod

Per controllare se il modulo interessato è attualmente caricato:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Ubuntu documenta anche una mitigazione manuale con una regola modprobe.d e lo scaricamento di algif_aead, ma questo approccio non è adatto a tutte le distribuzioni, in particolare ai sistemi della famiglia RHEL dove la funzionalità può essere compilata nel kernel.

---

5. Debian

Il security tracker di Debian elenca le versioni corrette per diverse release Debian:

Release Debian	Versione corretta
Bullseye security	5.10.251-3
Bookworm security	6.1.170-1
Trixie security	6.12.85-1
Forky	6.19.14-1
Sid	7.0.3-1

Aggiornamento consigliato:

sudo apt update
sudo apt upgrade
sudo reboot

Verifica:

uname -r
dpkg -l 'linux-image*' | grep ^ii

---

6. Red Hat Enterprise Linux

Red Hat ha pubblicato un bollettino di sicurezza e una pagina CVE per CVE-2026-31431. Red Hat lo descrive come un problema dell'interfaccia crittografica del kernel Linux in cui un utente locale può ottenere i privilegi di root. Red Hat classifica il problema come Important e dichiara che le correzioni vengono rilasciate attraverso i canali Red Hat pertinenti.

Azione consigliata:

sudo dnf update 'kernel*'
sudo reboot

Verifica:

uname -r
rpm -q kernel
rpm -q kernel-core

Per i sistemi con abbonamento Red Hat, controllate anche la pagina CVE ufficiale e gli avvisi di Red Hat per il pacchetto corretto esatto della vostra versione RHEL e del vostro kernel stream.

---

7. SUSE

SUSE classifica CVE-2026-31431 come important e ne traccia lo stato per prodotto e pacchetto. Alcuni pacchetti SUSE 15 SP7 risultano rilasciati, mentre diversi stream SUSE 16 e SUSE Linux Micro risultavano ancora interessati o in lavorazione sulla pagina CVE di SUSE al momento della verifica.

Azione consigliata:

sudo zypper refresh
sudo zypper update
sudo reboot

Verifica:

uname -r
rpm -q kernel-default

Controllate la pagina CVE di SUSE per lo stato esatto dei pacchetti del vostro prodotto, service pack e variante del kernel.

---

Mitigazione temporanea se non potete aggiornare subito

Per sistemi Oracle Linux / AlmaLinux / CloudLinux / famiglia RHEL

Per i sistemi della famiglia RHEL, la mitigazione temporanea più sicura è bloccare l'initcall algif_aead_init tramite la riga di comando del kernel e riavviare:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Verifica dopo il riavvio:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

oppure:

sudo grubby --info=ALL | grep initcall_blacklist

CloudLinux avverte espressamente che la comune mitigazione con modprobe.d potrebbe non funzionare su CloudLinux, AlmaLinux o altri sistemi della famiglia RHEL, perché algif_aead può essere compilato nel kernel. In quel caso, rmmod e le regole modprobe.d possono dare una falsa sensazione di protezione.

Dopo aver installato un kernel corretto, potete rimuovere la mitigazione temporanea:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

---

Per sistemi Ubuntu / Debian

Ubuntu documenta la seguente mitigazione, dove applicabile:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null

Verifica:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Potrebbe essere necessario un riavvio se il modulo non può essere scaricato in sicurezza.

---

Hardening per container e Kubernetes

Negli ambienti container, l'aggiornamento del kernel dell'host resta la correzione principale. È però fortemente consigliato un contenimento aggiuntivo.

CERT-EU raccomanda di bloccare la creazione di socket AF_ALG tramite policy seccomp per i carichi di lavoro in container e per le pipeline CI/CD. Docker documenta seccomp come funzionalità del kernel Linux usata per limitare le azioni dei container, e il profilo seccomp predefinito di Docker usa un modello allowlist.

Verifica seccomp in Docker:

grep CONFIG_SECCOMP= /boot/config-$(uname -r)

Atteso:

CONFIG_SECCOMP=y

Eseguite i container con il profilo seccomp predefinito, salvo motivi specifici per non farlo:

docker run --security-opt seccomp=default.json ...

Per Kubernetes, usate RuntimeDefault o un profilo seccomp personalizzato dove opportuno. Kubernetes supporta l'applicazione di profili seccomp a Pod e container, e la sua documentazione spiega come caricare e applicare i profili.

Esempio di security context in Kubernetes:

securityContext:
  seccompProfile:
    type: RuntimeDefault

---

Passo aggiuntivo per i server LiteSpeed Enterprise

Per i server che eseguono LiteSpeed Enterprise, in particolare negli ambienti di hosting con CloudLinux / CageFS, EuroVPS raccomanda di applicare il seguente passo aggiuntivo di hardening per LiteSpeed.

Si tratta di un hardening aggiuntivo per i server con il binario lscgid di LiteSpeed. L'aggiornamento del kernel o la mitigazione descritti sopra restano comunque necessari.

LiteSpeed 6.3.5 è indicato da LiteSpeed come release di sicurezza, tuning e correzione di bug, con modifiche relative a CloudLinux CageFS. La documentazione di LiteSpeed mostra inoltre che lscgid usa storicamente il permesso setuid nel normale funzionamento LiteSpeed/PHP.

Passo 2: hardening del binario lscgid

Prima verificate se LiteSpeed è installato:

/usr/local/lsws/bin/lshttpd -v

Poi scegliete una delle opzioni seguenti.

Opzione A: aggiornamento a LiteSpeed Enterprise 6.3.5 Build 5 o successiva (consigliata)

È l'opzione preferita. L'aggiornamento di LiteSpeed gestisce automaticamente l'hardening dei permessi di lscgid:

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.5

Dopo l'aggiornamento, riavviate LiteSpeed se necessario:

/usr/local/lsws/bin/lswsctrl restart

Opzione B: correzione rapida se non siete pronti ad aggiornare

Se non potete aggiornare LiteSpeed subito, rimuovete manualmente il permesso setuid dal binario lscgid ora:

chmod u-s /usr/local/lsws/bin/lscgid.*

Poi riavviate LiteSpeed:

/usr/local/lsws/bin/lswsctrl restart

Checklist di verifica

Eseguite i controlli seguenti dopo aver applicato aggiornamenti o mitigazioni.

1. Identificare sistema operativo e kernel

cat /etc/os-release
uname -r

2. Controllare i pacchetti kernel installati

Sistemi basati su RPM:

rpm -q kernel
rpm -q kernel-core

Sistemi Debian/Ubuntu:

dpkg -l 'linux-image*' | grep ^ii

3. Confermare che il kernel in esecuzione sia quello corretto

Dopo il riavvio:

uname -r

Confrontate la versione del kernel in esecuzione con la versione corretta ufficiale del produttore per il vostro sistema operativo.

4. Confermare che la mitigazione sia attiva, se usata

Per i sistemi della famiglia RHEL con mitigazione grubby:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

Per la mitigazione del modulo su Ubuntu/Debian:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

5. Verifica KernelCare

kcarectl --update
kcarectl --info | grep CVE-2026-31431

La CVE deve comparire come corretta nell'output di KernelCare dove è disponibile una live patch.

---

Note operative importanti

Non eseguite codice pubblico di proof-of-concept dell'exploit sui server di produzione.

---

Piano d'azione raccomandato da EuroVPS

EuroVPS raccomanda il seguente piano d'azione:

1. Oltre a patch e riavvio: applicate policy seccomp ai carichi di lavoro in container, dismettete i sistemi operativi a fine vita, e su LiteSpeed Enterprise aggiornate a 6.3.5 Build 5 o rimuovete il bit setuid da lscgid.

Vi serve aiuto?

Se volete che i nostri ingegneri verifichino, aggiornino, mitighino e controllino il vostro server, aprite un ticket di assistenza dall'area clienti con l'hostname o l'IP. Condividete l'accesso root solo tramite il campo credenziali sicuro del ticket, mai nel testo del ticket.

Link ufficiali dei produttori e riferimenti:

[1] Divulgazione ufficiale Copy Fail: https://copy.fail/ [2] Ubuntu CVE tracker, CVE-2026-31431: https://ubuntu.com/security/CVE-2026-31431 [3] Blog Ubuntu, correzioni disponibili per la vulnerabilità Copy Fail: https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available [4] Avviso AlmaLinux, CVE-2026-31431 Copy Fail: https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ [5] Blog CloudLinux, aggiornamento del kernel per CVE-2026-31431 Copy Fail: https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update [6] Pagina incidente / stato CloudLinux: https://cloudlinux.statuspage.io/incidents/642sgcmntkkk [7] Pagina CVE di Red Hat, CVE-2026-31431: https://access.redhat.com/security/cve/CVE-2026-31431 [8] Bollettino di sicurezza Red Hat: https://access.redhat.com/security/vulnerabilities/RHSB-2026-02 [9] Pagina CVE di SUSE, CVE-2026-31431: https://www.suse.com/security/cve/CVE-2026-31431 [10] Debian security tracker, CVE-2026-31431: https://security-tracker.debian.org/tracker/CVE-2026-31431 [11] Documentazione seccomp di Docker: https://docs.docker.com/engine/security/seccomp/ [12] Documentazione seccomp di Kubernetes: https://kubernetes.io/docs/tutorials/security/seccomp/ [13] Oracle Linux 7 / 8, UEK R6: https://linux.oracle.com/errata/ELSA-2026-50255.html [14] Oracle Linux 8 / 9, UEK R7: https://linux.oracle.com/errata/ELSA-2026-50253.html [15] Oracle Linux 9 / 10, UEK R8: https://linux.oracle.com/errata/ELSA-2026-50254.html