Für Änderungskontrolle auf ein Release-Tag pinnen: https://raw.githubusercontent.com/haydenjames/dirty-frag-check/v1.0.4/dirty-frag-check.sh.

-q für einzeilige Fleet-Ausgabe. -h für Hilfe. Exit 0 ok, 1 verwundbar, 2 unbekannt.

Fleet-Nutzung

Exit-Codes (0 ok, 1 verwundbar, 2 unbekannt) funktionieren mit allem, das nach Status aggregiert.

Anforderungen

bash 4+, plus die üblichen awk/grep/sed/lsmod/modprobe. Für den Check selbst ist kein Root erforderlich. Zum Anwenden von Gegenmaßnahmen ist Root nötig.

Was geprüft wird

1. Modulstatus. Ob die vom Advisory betroffenen Module — esp4, esp6, ipcomp, ipcomp6 (CVE-2026-43284) und rxrpc (CVE-2026-43500) — geladen, verfügbar oder nicht vorhanden sind.
2. Gegenmaßnahmen. Sucht nach Modprobe-Blacklist-Dateien und verifiziert, dass die Blacklist tatsächlich greift, via modprobe -n -v. Meldet SELinux- und AppArmor-Status. Erkennt KernelCare-Livepatch via kcarectl --patch-info.
3. Kernel-Paket vs. laufender Kernel. Erkennt den Fall, dass Sie einen gepatchten Kernel installiert, aber nicht neu gestartet haben.
4. Laufender Kernel vs. bekannte Fix-Version. Für RHEL-Familien-Distributionen (AlmaLinux, Rocky, RHEL, CloudLinux) vergleicht uname -r mit der vom Hersteller veröffentlichten Fix-Version für dieses Release. Best-Effort; verifizieren Sie gegen Ihren Distributions-Tracker.

Bewertungen

• OK — KernelCare-Livepatch angewendet, laufender Kernel bei/nach dem veröffentlichten Fix, oder alle relevanten Module blacklisted.
• MITIGATED — Kernel ungepatcht, aber jedes erreichbare Modul ist blacklisted, sodass der Bug nicht ausgelöst werden kann. Patchen, sobald möglich.
• REBOOT NEEDED — gepatchter Kernel installiert, Sie laufen noch auf dem alten.
• VULNERABLE — laufender Kernel als älter als der Fix verifiziert und ein Kernel-Upgrade verfügbar, oder Module geladen mit ausstehendem Upgrade.
• WAITING ON VENDOR PATCH — laufender Kernel älter als der Upstream-Fix, derzeit kein Kernel-Upgrade verfügbar. Häufig bei Rocky/CloudLinux, die AlmaLinux um einen Build hinterherhinken, oder wenn die Distribution unter einer anderen Versionszeichenkette backportet.
• AT RISK — KernelCare-verwalteter Host ohne den Dirty-Frag-Livepatch, oder Module verfügbar mit ausstehendem Upgrade.
• LIKELY PATCHED — Module geladen, aber der laufende Kernel ist bei/nach dem veröffentlichten Fix. Das Skript kann den Patch-Level eines geladenen Moduls nicht inspizieren; es verlässt sich auf Hersteller-Metadaten.
• UNKNOWN — keine Fix-Versionstabelle für diese Distribution (Ubuntu, Debian, TuxCare ELS) und kein anderes starkes Signal. Mit dem Distributions-Tracker abgleichen.

Übergangs-Gegenmaßnahme

Verwenden Sie dies, wenn Ihre Distribution noch kein Kernel-Update ausgeliefert hat oder wenn Sie nicht bald neu starten können und die erreichbaren Module entladen müssen:

Wenn rmmod „module is in use“ meldet, nutzt etwas auf dem System aktiv IPsec oder AF_RXRPC (manche VPNs, AFS-Clients, strongSwan, Libreswan). Erzwingen Sie das Entladen nicht. Patchen Sie stattdessen den Kernel und starten Sie neu.

KernelCare-/TuxCare-ELS-Nutzer: Livepatches für CVE-2026-43284 decken dies ohne Neustart ab. Prüfen Sie kcarectl --patch-info.

Zielsysteme

Ausgerichtet auf AlmaLinux 8/9/10, Rocky, RHEL, CloudLinux 8/9/10, Ubuntu, Debian und CentOS 7 (TuxCare ELS / KernelCare). Die Fix-Versionstabelle ist RHEL-Familien-spezifisch; Ubuntu/Debian fallen auf Paketmanager-Frische zurück. Bestätigen Sie jedes grüne Ergebnis gegen den Tracker Ihrer Distribution.

Diskussion

• AlmaLinux-Advisory: Dirty Frag
• CloudLinux / KernelCare: Gegenmaßnahme und Kernel-Update
• cPanel: Security-Advisory
• Forum-Thread: Dirty Frag check script (linuxcommunity.io)
• Begleit-Checker: CVE-2026-31431-check
• Issues: GitHub

Lizenz

MIT — siehe LICENSE.