Dirty Frag im Linux-Kernel: Schwachstelle und Korrektur

Zuletzt aktualisiert: 9. Mai 2026

Zusammenfassung

Eine Schwachstelle zur lokalen Privilegieneskalation im Linux-Kernel, bekannt als Dirty Frag, wurde bekannt gemacht. Sie wird hauptsächlich geführt als:

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

Dirty Frag kann es einem lokalen, nicht privilegierten Benutzer ermöglichen, Root-Rechte zu erlangen. Es handelt sich nicht um einen direkten Remote-Exploit über das Netzwerk, für Hosting-Server ist die Schwachstelle aber ernst, weil ein Angreifer zunächst über eine kompromittierte Website, ein SSH/SFTP-Konto, eine Container-Workload oder ein lokales Benutzerkonto eingeschränkten Zugang erlangen kann. cPanel bestätigt, dass das Problem den Linux-Kernel selbst betrifft und in mehreren Linux-Distributionen vorhanden ist. (cPanel Support)

---

Betroffene Systeme

Dirty Frag betrifft mehrere Linux-Distributionen und Kernel-Streams. Zu den bestätigt betroffenen Plattformen gehören:

• 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 und weitere unterstützte Ubuntu-Releases
• Oracle-Linux-Systeme mit betroffenen RHCK- oder UEK-Kerneln
• Weitere Linux-Distributionen mit betroffenen Kernel-Versionen

CloudLinux bestätigt, dass CloudLinux 7 Standard nicht betroffen ist, während CloudLinux 7 Hybrid, 8, 9 und 10 betroffen sind. CloudLinux 9 und 10 nutzen den Kernel-Stream von AlmaLinux. (CloudLinux Blog)

---

Erforderliche Maßnahme

Die empfohlene Korrektur besteht darin, den vom Hersteller gepatchten Kernel zu installieren und den Server neu zu starten.

Aktuellen Kernel prüfen:

uname -r

Nach Update und Neustart erneut prüfen:

uname -r

Die Installation des Kernel-Pakets allein genügt nicht. Der Server muss in den gepatchten Kernel booten.

---

Update-Anleitungen je Betriebssystem

AlmaLinux 8 / 9 / 10

Kernel aktualisieren:

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

Prüfung:

uname -r
rpm -q kernel

Erwartete gepatchte Versionen:

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 bestätigt diese gepatchten Kernel-Versionen in seinem Dirty-Frag-Advisory. (AlmaLinux OS)

---

CloudLinux

CloudLinux 7 Hybrid / 8

Wenn der gepatchte Kernel in den Stable-Repositories verfügbar ist:

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

Wenn der gepatchte Kernel nur im Testing-/Beta-Repository verfügbar ist:

Für CloudLinux 8:

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

Für CloudLinux 7 Hybrid:

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

Erwartete gepatchte Versionen:

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 nennt diese Zielversionen für die gepatchten Kernel-Streams CL7h und CL8. (CloudLinux Blog)

---

CloudLinux 9 / 10

CloudLinux 9 und 10 nutzen den Kernel-Stream von AlmaLinux. Wenn der gepatchte Kernel aus den Stable-Repositories verfügbar ist:

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

Erwartete gepatchte Versionen:

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

Ist der gepatchte Kernel in den Stable-Repositories oder lokalen Mirrors noch nicht sichtbar, verwenden Sie vorübergehend das Testing-Repository von AlmaLinux.

Für 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

Nach dem Neustart:

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

Für 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

Nach dem Neustart:

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

Verwenden Sie das Testing-Repository nur für das Update der Kernel-Pakete und deaktivieren Sie es direkt nach der Prüfung wieder. CloudLinux dokumentiert diesen vorübergehenden Ablauf mit dem Testing-Repository für CL9 und CL10. (CloudLinux Blog)

---

RHEL / Rocky Linux / Oracle Linux

Für Systeme der RHEL-Familie:

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

Für Oracle-Linux-Systeme mit UEK aktualisieren Sie auch die UEK-Pakete:

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

Prüfung:

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

Red Hat bestätigt, dass Dirty Frag RHEL 8, 9, 10 und OpenShift 4 betrifft, und empfiehlt je nach Verfügbarkeit der Patches Kernel-Updates oder die Gegenmaßnahme. (Red Hat Customer Portal)

---

Ubuntu / Debian

System-Kernel aktualisieren:

apt update
apt full-upgrade -y
reboot

Prüfung:

uname -r
dpkg -l | grep linux-image

Ubuntu bestätigt, dass die Korrektur über die Linux-Kernel-Image-Pakete ausgeliefert wird, und empfiehlt einen Neustart in den aktualisierten Kernel. (Ubuntu)

---

SUSE / openSUSE

Kernel aktualisieren:

zypper refresh
zypper update kernel-default
reboot

Prüfung:

uname -r
rpm -qa | grep kernel

---

Vorübergehende Gegenmaßnahme

Ist noch kein gepatchter Kernel oder Livepatch verfügbar, blockieren Sie die betroffenen Module:

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

Prüfung:

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

Diese Gegenmaßnahme blockiert esp4, esp6 und rxrpc, die betroffenen Modulpfade des Kernels. CloudLinux, Ubuntu und Red Hat dokumentieren dieses Blockieren der Module als vorübergehende Gegenmaßnahme. (CloudLinux Blog)

---

Wichtige Warnung

Wenden Sie diese Gegenmaßnahme nicht ungeprüft auf Systemen an, die Folgendes nutzen:

• IPsec
• StrongSwan
• Libreswan
• VPN-Gateways
• AFS-/RxRPC-Workloads

Das Blockieren von esp4 und esp6 kann den IPsec-Datenverkehr unterbrechen, und das Blockieren von rxrpc kann AFS/RxRPC-Workloads beeinträchtigen. Ubuntu und Red Hat weisen beide auf diese betriebliche Auswirkung hin. (Ubuntu)

---

Zusätzlicher Schritt für Ubuntu / Debian

Erzeugen Sie auf Ubuntu- und Debian-Systemen nach Anwendung der Gegenmaßnahme das initramfs neu:

update-initramfs -u -k all

Prüfen Sie anschließend erneut:

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

Ubuntu empfiehlt die Neuerzeugung des initramfs, damit die betroffenen Module auch beim Booten blockiert bleiben. (Ubuntu)

---

Page Cache nach der Gegenmaßnahme leeren

Leeren Sie nach Anwendung der Gegenmaßnahme den Page Cache:

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

CloudLinux weist darauf hin, dass der Exploit legitime System-Binaries im Page Cache verändern kann; deshalb wird das Leeren des Page Cache nach der Gegenmaßnahme auf möglicherweise angegriffenen Systemen empfohlen. (CloudLinux Blog)

---

Gegenmaßnahme nach dem Patchen entfernen

Nachdem der gepatchte Kernel installiert ist und der Server in ihn neu gestartet wurde:

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

Für Ubuntu / Debian:

update-initramfs -u -k all

Neustart, falls erforderlich:

reboot

---

KernelCare

Wenn KernelCare installiert ist:

kcarectl --update

Abdeckung prüfen:

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

Erscheint die CVE nicht in der Ausgabe, deckt KernelCare den laufenden Kernel möglicherweise noch nicht ab. Spielen Sie in diesem Fall das Kernel-Update des Herstellers oder die vorübergehende Gegenmaßnahme ein. cPanel und CloudLinux nennen beide KernelCare als verfügbaren Livepatch-Weg, wo Abdeckung besteht. (cPanel Support)

---

Prüfliste zur Verifizierung

Führen Sie nach dem Patchen oder der Gegenmaßnahme Folgendes aus:

cat /etc/os-release
uname -r

Für Systeme der RHEL-Familie:

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

Für Ubuntu / Debian:

dpkg -l | grep linux-image

Betroffene Module prüfen:

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

Status der Gegenmaßnahme bestätigen:

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

---

Empfehlung von EuroVPS

Beschränken Sie unnötigen SSH-, SFTP-, Shell- und Panel-Zugang, prüfen Sie den Server auf kompromittierte Websites, unerwartete lokale Benutzer oder Privilegieneskalation, und migrieren Sie Betriebssysteme am Ende ihres Lebenszyklus.

---

Brauchen Sie Unterstützung?

Eröffnen Sie ein Support-Ticket im Kundenbereich; auf Servern, auf denen wir Root-Zugang haben, spielen unsere Ingenieure den Patch oder die Gegenmaßnahme ein und verifizieren die Korrektur.