ZDI-CAN-33367: zero-day root nel kernel Linux, mitigazione per CloudLinux

Chi gestisce hosting condiviso su CloudLinux ha un problema aperto dal 22 ottobre: una falla nel kernel Linux, tracciata come ZDI-CAN-33367 e priva di CVE, permette a un utente locale qualsiasi di riscrivere file che può solo leggere, fino ad arrivare a root. Lo riporta il blog di sicurezza di CloudLinux, aggiornato il 23 ottobre alle 14:59 UTC. Un exploit pubblico esiste già e, su un server condiviso, basta un singolo account cliente per arrivare al kernel che serve tutti i tenant della macchina.

Il bug risiede nella funzione di rete skb_zerocopy. Ricercatori indipendenti lo classificano con un punteggio CVSS di 7.8, Kernel developers had reportedly received a separate report about the same issue the previous week, with a patch expected. La patch per il kernel è stata postata sulla mailing list netdev il 22 ottobre ma non è ancora stata integrata.

Chi è esposto

CloudLinux precisa che la condizione decisiva non è la versione ma se gli utenti normali possono creare proprie namespace di rete. Chi aveva già applicato la correzione Dirty Frag (CVE-2026-43284) non è coperto: quella patch risolve un problema diverso nella stessa area del kernel.

Versione	Esposizione	Patch kernel	Livepatch
CloudLinux 7 (kernel 3.10)	No, non colpita	non necessaria	non necessario
CloudLinux 7 hybrid (kernel 4.18)	Sì, di serie	in attesa del fix upstream	in preparazione
CloudLinux 8 (kernel 4.18)	Condizionata: esposta se installata prima di metà 2024	in attesa	in corso
CloudLinux 8 ELS (kernel 5.14)	Condizionata, stesso criterio	in attesa sul canale extended-support	nessuno stream disponibile
CloudLinux 9 (kernel 5.14)	Condizionata, stesso criterio	nessun kernel corretto	in revisione
CloudLinux 9 ELS	Condizionata, stesso criterio	in attesa	in preparazione
CloudLinux 10 (kernel 6.12)	Chiusa di default	nessun kernel corretto	rilasciato in produzione
CloudLinux per Ubuntu 22.04	Chiusa di default	segue il canale Ubuntu/Canonical	non iniziato

Come verificare e mitigare

Il controllo è di sola lettura:

sysctl user.max_user_namespaces

Un valore 0 significa percorso chiuso. Qualsiasi altro numero, su una versione esposta, va trattato come server a rischio oggi stesso. La mitigazione si applica senza riavvio:

echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

Il costo pratico: Podman e Docker rootless, LXC non privilegiato e Flatpak smettono di funzionare per gli account ordinari. Su hosting condiviso classico l'impatto è nullo; su server dove i clienti usano container propri va valutato.

CageFS, l'isolamento del filesystem per account, non interviene su questo percorso: CloudLinux ha verificato che il danno avviene dentro la memoria condivisa del kernel, non attraverso il filesystem.