Dirty Frag nel kernel Linux: cosa sapere e come correggere

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

Ultimo aggiornamento: 9 maggio 2026

Sintesi

È stata divulgata una vulnerabilità di escalation locale dei privilegi nel kernel Linux, nota come Dirty Frag. È tracciata principalmente come:

• CVE-2026-43284: IPsec ESP / esp4 / esp6
• CVE-2026-43500: RxRPC / rxrpc

Dirty Frag può consentire a un utente locale senza privilegi di ottenere i privilegi di root. Non è un exploit di rete remoto diretto, ma è grave per i server di hosting, perché un attaccante può prima ottenere un accesso limitato tramite un sito web compromesso, un account SSH/SFTP, un carico di lavoro in container o un account utente locale. cPanel conferma che il problema riguarda il kernel Linux stesso ed è presente in più distribuzioni Linux. (cPanel Support)

---

Sistemi interessati

Dirty Frag interessa più distribuzioni Linux e kernel stream. Le piattaforme confermate come interessate includono:

• AlmaLinux 8, 9, 10
• Rocky Linux 8, 9, 10
• CloudLinux 7 Hybrid, 8, 9, 10
• Red Hat Enterprise Linux 8, 9, 10
• Ubuntu 20.04, 22.04, 24.04 e altre release Ubuntu supportate
• Sistemi Oracle Linux che usano kernel RHCK o UEK interessati
• Altre distribuzioni Linux con versioni del kernel interessate

CloudLinux conferma che CloudLinux 7 standard non è interessato, mentre CloudLinux 7 Hybrid, 8, 9 e 10 lo sono. CloudLinux 9 e 10 usano il kernel stream di AlmaLinux. (CloudLinux Blog)

---

Azione richiesta

La correzione consigliata è installare il kernel corretto dal produttore e riavviare il server.

Verifica del kernel attuale:

uname -r

Dopo l'aggiornamento e il riavvio, verificate di nuovo:

uname -r

Installare il pacchetto del kernel da solo non basta. Il server deve avviarsi sul kernel corretto.

---

Istruzioni di aggiornamento per sistema operativo

AlmaLinux 8 / 9 / 10

Aggiornamento del kernel:

dnf clean metadata
dnf update 'kernel*' -y
reboot

Verifica:

uname -r
rpm -q kernel

Versioni corrette attese:

AlmaLinux 8:  kernel-4.18.0-553.123.2.el8_10 or newer
AlmaLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

AlmaLinux conferma queste versioni corrette del kernel nel proprio avviso su Dirty Frag. (AlmaLinux OS)

---

CloudLinux

CloudLinux 7 Hybrid / 8

Se il kernel corretto è disponibile nei repository stable:

yum update 'kernel*' -y
reboot
uname -r

Se il kernel corretto è disponibile solo nel repository testing/beta:

Per CloudLinux 8:

yum --enablerepo=cloudlinux-updates-testing update 'kernel*' -y
reboot
uname -r

Per CloudLinux 7 Hybrid:

yum --enablerepo=cl7h_beta update 'kernel*' -y
reboot
uname -r

Versioni corrette attese:

CloudLinux 7 Hybrid: kernel-4.18.0-553.123.2.lve.el7h or newer
CloudLinux 8:        kernel-4.18.0-553.123.2.lve.el8 or newer

CloudLinux indica queste versioni di destinazione per i kernel stream corretti di CL7h e CL8. (CloudLinux Blog)

---

CloudLinux 9 / 10

CloudLinux 9 e 10 usano il kernel stream di AlmaLinux. Se il kernel corretto è disponibile dai repository stable:

dnf update 'kernel*' -y
reboot
uname -r

Versioni corrette attese:

CloudLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
CloudLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

Se il kernel corretto non è ancora visibile dai repository stable o dai mirror locali, usate temporaneamente il repository di test di AlmaLinux.

Per CloudLinux 10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
dnf update 'kernel*' -y
reboot

Dopo il riavvio:

uname -r
dnf config-manager --disable almalinux-testing

Per CloudLinux 9:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm
dnf update 'kernel*' -y
reboot

Dopo il riavvio:

uname -r
dnf config-manager --disable almalinux-testing

Usate il repository di test solo per aggiornare i pacchetti del kernel, e disattivatelo subito dopo la verifica. CloudLinux documenta questo flusso temporaneo con il repository di test per CL9 e CL10. (CloudLinux Blog)

---

RHEL / Rocky Linux / Oracle Linux

Per i sistemi della famiglia RHEL:

dnf clean all
dnf update 'kernel*' -y
reboot

Per i sistemi Oracle Linux con UEK, aggiornate anche i pacchetti UEK:

dnf update 'kernel*' 'kernel-uek*' -y
reboot

Verifica:

uname -r
rpm -q kernel kernel-core kernel-uek 2>/dev/null

Red Hat conferma che Dirty Frag interessa RHEL 8, 9, 10 e OpenShift 4, e raccomanda aggiornamenti del kernel o la mitigazione a seconda della disponibilità delle patch. (Red Hat Customer Portal)

---

Ubuntu / Debian

Aggiornamento del kernel di sistema:

apt update
apt full-upgrade -y
reboot

Verifica:

uname -r
dpkg -l | grep linux-image

Ubuntu conferma che la correzione è distribuita tramite i pacchetti Linux kernel image e raccomanda il riavvio sul kernel aggiornato. (Ubuntu)

---

SUSE / openSUSE

Aggiornamento del kernel:

zypper refresh
zypper update kernel-default
reboot

Verifica:

uname -r
rpm -qa | grep kernel

---

Mitigazione temporanea

Se un kernel corretto o una livepatch non sono ancora disponibili, bloccate i moduli interessati:

cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

rmmod esp4 esp6 rxrpc 2>/dev/null || true

Verifica:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Questa mitigazione blocca esp4, esp6 e rxrpc, che sono i percorsi dei moduli del kernel interessati. CloudLinux, Ubuntu e Red Hat documentano tutti questo approccio di blocco dei moduli come mitigazione temporanea. (CloudLinux Blog)

---

Avvertenza importante

Non applicate questa mitigazione senza una verifica sui sistemi che usano:

• IPsec
• StrongSwan
• Libreswan
• Gateway VPN
• Carichi di lavoro AFS / RxRPC

Bloccare esp4 ed esp6 può interrompere il traffico IPsec, e bloccare rxrpc può influire sui carichi di lavoro AFS/RxRPC. Ubuntu e Red Hat segnalano entrambi questo impatto operativo. (Ubuntu)

---

Passo aggiuntivo per Ubuntu / Debian

Sui sistemi Ubuntu e Debian, rigenerate l'initramfs dopo aver applicato la mitigazione:

update-initramfs -u -k all

Poi verificate di nuovo:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Ubuntu raccomanda di rigenerare l'initramfs affinché i moduli interessati restino bloccati durante l'avvio. (Ubuntu)

---

Svuotare la page cache dopo la mitigazione

Dopo aver applicato la mitigazione, svuotate la page cache:

sync
echo 3 > /proc/sys/vm/drop_caches

CloudLinux segnala che l'exploit può modificare binari di sistema legittimi nella page cache, quindi svuotare la page cache è consigliato dopo la mitigazione sui sistemi potenzialmente presi di mira. (CloudLinux Blog)

---

Rimuovere la mitigazione dopo l'aggiornamento

Dopo che il kernel corretto è installato e il server è stato riavviato su di esso:

rm -f /etc/modprobe.d/dirtyfrag.conf

Per Ubuntu / Debian:

update-initramfs -u -k all

Riavviate se necessario:

reboot

---

KernelCare

Se KernelCare è installato:

kcarectl --update

Verifica della copertura:

kcarectl --patch-info | grep -E 'CVE-2026-43284|CVE-2026-43500|Dirty Frag'

Se la CVE non compare nell'output, KernelCare potrebbe non coprire ancora il kernel in esecuzione. In quel caso, applicate l'aggiornamento del kernel del produttore o la mitigazione temporanea. cPanel e CloudLinux indicano entrambi KernelCare come percorso di livepatch disponibile dove esiste la copertura. (cPanel Support)

---

Checklist di verifica

Eseguite quanto segue dopo l'aggiornamento o la mitigazione:

cat /etc/os-release
uname -r

Per i sistemi della famiglia RHEL:

rpm -q kernel kernel-core kernel-uek 2>/dev/null

Per Ubuntu / Debian:

dpkg -l | grep linux-image

Controllo dei moduli interessati:

lsmod | grep -E 'esp4|esp6|rxrpc'

Conferma dello stato della mitigazione:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

---

Raccomandazione di EuroVPS

Limitate gli accessi SSH, SFTP, shell e pannello non necessari, controllate il server alla ricerca di siti web compromessi, utenti locali imprevisti o escalation dei privilegi, e migrate i sistemi operativi a fine vita.

---

Vi serve aiuto?

Aprite un ticket di assistenza dall'area clienti e, sui server dove abbiamo accesso root, i nostri ingegneri applicheranno la patch o la mitigazione e verificheranno la correzione.