Dirty Frag no kernel Linux: o que saber e como corrigir

Última atualização: 9 de maio de 2026

Resumo

Foi divulgada uma vulnerabilidade de escalada local de privilégios no kernel Linux, conhecida como Dirty Frag. É registada principalmente como:

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

A Dirty Frag pode permitir que um utilizador local sem privilégios obtenha privilégios de root. Não é um exploit remoto direto pela rede, mas é grave para servidores de hosting, porque um atacante pode primeiro obter acesso limitado através de um website comprometido, de uma conta SSH/SFTP, de uma carga de trabalho em container ou de uma conta de utilizador local. A cPanel confirma que o problema afeta o próprio kernel Linux e está presente em várias distribuições Linux. (cPanel Support)

---

Sistemas afetados

A Dirty Frag afeta várias distribuições Linux e kernel streams. As plataformas confirmadas como afetadas incluem:

• 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 outras versões suportadas do Ubuntu
• Sistemas Oracle Linux que utilizam kernels RHCK ou UEK afetados
• Outras distribuições Linux com versões de kernel afetadas

A CloudLinux confirma que o CloudLinux 7 standard não é afetado, enquanto o CloudLinux 7 Hybrid, 8, 9 e 10 são afetados. O CloudLinux 9 e 10 utilizam o kernel stream do AlmaLinux. (CloudLinux Blog)

---

Ação necessária

A correção recomendada é instalar o kernel corrigido do fornecedor e reiniciar o servidor.

Verificar o kernel atual:

uname -r

Depois de atualizar e reiniciar, verifique de novo:

uname -r

Instalar o pacote do kernel por si só não chega. O servidor tem de arrancar no kernel corrigido.

---

Instruções de atualização por sistema operativo

AlmaLinux 8 / 9 / 10

Atualizar o kernel:

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

Verificação:

uname -r
rpm -q kernel

Versões corrigidas esperadas:

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

A AlmaLinux confirma estas versões corrigidas do kernel no seu aviso sobre a Dirty Frag. (AlmaLinux OS)

---

CloudLinux

CloudLinux 7 Hybrid / 8

Se o kernel corrigido estiver disponível nos repositórios stable:

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

Se o kernel corrigido só estiver disponível no repositório testing/beta:

Para CloudLinux 8:

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

Para CloudLinux 7 Hybrid:

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

Versões corrigidas esperadas:

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

A CloudLinux indica estas versões alvo para os kernel streams corrigidos CL7h e CL8. (CloudLinux Blog)

---

CloudLinux 9 / 10

O CloudLinux 9 e 10 utilizam o kernel stream do AlmaLinux. Se o kernel corrigido estiver disponível nos repositórios stable:

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

Versões corrigidas esperadas:

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 o kernel corrigido ainda não estiver visível nos repositórios stable ou nos mirrors locais, utilize temporariamente o repositório de testing do AlmaLinux.

Para 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

Depois de reiniciar:

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

Para 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

Depois de reiniciar:

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

Utilize o repositório de testing apenas para atualizar os pacotes do kernel e desative-o imediatamente após a verificação. A CloudLinux documenta este fluxo temporário com repositório de testing para CL9 e CL10. (CloudLinux Blog)

---

RHEL / Rocky Linux / Oracle Linux

Para sistemas da família RHEL:

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

Para sistemas Oracle Linux com UEK, atualize também os pacotes UEK:

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

Verificação:

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

A Red Hat confirma que a Dirty Frag afeta RHEL 8, 9, 10 e OpenShift 4, e recomenda atualizações do kernel ou mitigação consoante a disponibilidade dos patches. (Red Hat Customer Portal)

---

Ubuntu / Debian

Atualizar o kernel do sistema:

apt update
apt full-upgrade -y
reboot

Verificação:

uname -r
dpkg -l | grep linux-image

A Ubuntu confirma que a correção é fornecida através dos pacotes de imagem do kernel Linux e recomenda reiniciar no kernel atualizado. (Ubuntu)

---

SUSE / openSUSE

Atualizar o kernel:

zypper refresh
zypper update kernel-default
reboot

Verificação:

uname -r
rpm -qa | grep kernel

---

Mitigação temporária

Se ainda não houver um kernel corrigido ou um livepatch disponível, bloqueie os módulos afetados:

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ção:

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

Esta mitigação bloqueia esp4, esp6 e rxrpc, que são os caminhos de módulos do kernel afetados. A CloudLinux, a Ubuntu e a Red Hat documentam esta abordagem de bloqueio de módulos como mitigação temporária. (CloudLinux Blog)

---

Aviso importante

Não aplique esta mitigação sem análise em sistemas que utilizam:

• IPsec
• StrongSwan
• Libreswan
• Gateways VPN
• Cargas de trabalho AFS / RxRPC

Bloquear esp4 e esp6 pode interromper o tráfego IPsec, e bloquear rxrpc pode afetar cargas de trabalho AFS/RxRPC. Tanto a Ubuntu como a Red Hat assinalam este impacto operacional. (Ubuntu)

---

Passo adicional para Ubuntu / Debian

Em sistemas Ubuntu e Debian, regenere o initramfs depois de aplicar a mitigação:

update-initramfs -u -k all

Depois verifique de novo:

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

A Ubuntu recomenda regenerar o initramfs para que os módulos afetados se mantenham bloqueados durante o arranque. (Ubuntu)

---

Limpar a page cache depois da mitigação

Depois de aplicar a mitigação, limpe a page cache:

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

A CloudLinux nota que o exploit pode modificar binários legítimos do sistema na page cache, pelo que se recomenda limpar a page cache depois da mitigação em sistemas que possam ter sido visados. (CloudLinux Blog)

---

Remover a mitigação depois do patching

Depois de o kernel corrigido estar instalado e de o servidor ter reiniciado nele:

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

Para Ubuntu / Debian:

update-initramfs -u -k all

Reinicie se necessário:

reboot

---

KernelCare

Se o KernelCare estiver instalado:

kcarectl --update

Verificar a cobertura:

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

Se a CVE não aparecer no resultado, o KernelCare pode ainda não cobrir o kernel em execução. Nesse caso, aplique a atualização do kernel do fornecedor ou a mitigação temporária. Tanto a cPanel como a CloudLinux referem o KernelCare como um caminho de livepatch disponível onde existe cobertura. (cPanel Support)

---

Lista de verificação

Execute o seguinte depois do patching ou da mitigação:

cat /etc/os-release
uname -r

Para sistemas da família RHEL:

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

Para Ubuntu / Debian:

dpkg -l | grep linux-image

Verificar os módulos afetados:

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

Confirmar o estado da mitigação:

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

---

Recomendação da EuroVPS

Restrinja o acesso SSH, SFTP, shell e de painel desnecessário, reveja o servidor em busca de websites comprometidos, utilizadores locais inesperados ou escalada de privilégios, e migre os sistemas operativos em fim de vida.

---

Precisa de ajuda?

Abra um ticket de suporte a partir da área de cliente e, nos servidores onde temos acesso root, os nossos engenheiros aplicam o patch ou a mitigação e verificam a correção.