vcheck

Überprüft einen entfernten Linux-Host per SSH auf die Kernel-Modul-Sicherheitslücken Copy Fail und Dirty Frag und wendet optional Gegenmaßnahmen an:

CVE	Name	Betroffene Module
CVE-2026-31431	Copy Fail	algif_aead
CVE-2026-43284	Dirty Frag (IPsec)	esp4, esp6, ipcomp4, ipcomp6, xfrm_user
CVE-2026-43500	Dirty Frag (RxRPC)	rxrpc, kafs

Für jedes betroffene Modul meldet vcheck, ob es derzeit geladen, in den laufenden Kernel eingebaut ist, ob es in der Vergangenheit im Kernel-Log aufgetaucht ist, ob live AF_ALG-Sockets vorhanden sind (nur Copy Fail) und ob es bereits unter /etc/modprobe.d/ auf der Blacklist steht.

Mit -fix meldet vcheck den Anfangszustand, schreibt für jedes noch nicht auf der Blacklist stehende Modul einen cve-XXXX-XXXXX-disable.conf-Snippet, führt dann die Prüfungen erneut durch und meldet den Endzustand. Mit -fix -unload versucht vcheck zusätzlich, betroffene Module, die vor der Reparatur geladen waren, zu entladen, und überprüft dann mit dem endgültigen Scan, ob sie noch geladen sind. Mit -fix -rebuild-initramfs baut vcheck (nur) für den aktuell laufenden Kernel die Initramfs neu auf, nachdem ein Snippet geschrieben wurde, sodass die Blacklist in das nächste Startabbild eingebaut wird. Ältere Kernel-Einträge behalten ihre ursprüngliche Initramfs als Fallback.

Verwenden Sie -fix erst nach einem reinen Prüflauf

Führen Sie vcheck immer zuerst ohne -fix aus. Lesen Sie den Bericht und bestätigen Sie, dass die betroffenen Module auf diesem Host sicher deaktiviert werden können, bevor Sie mit -fix erneut ausführen. Das Deaktivieren von Kernel-Modulen, von denen legitime Arbeitslasten abhängen, kann Benutzer beeinträchtigen und Anwendungen zum Absturz bringen.

Insbesondere:

• Betrachten Sie -fix nur dann als sicher, wenn keines der betroffenen Module derzeit geladen ist – d. h. jedes Modul wird entweder als mitigated oder module not blacklisted gemeldet (keine VULNERABLE- oder blacklisted but currently loaded-Zeilen). Ein geladenes Modul bedeutet fast immer, dass etwas auf dem Host es aktiv nutzt; überprüfen Sie das, bevor Sie es auf die Blacklist setzen.
• Die IPsec-Module (esp4, esp6, ipcomp4, ipcomp6, xfrm_user) werden für jede IPsec/strongSwan/WireGuard-over-IPsec/IKE-Bereitstellung benötigt. Die Module ipcomp4/ipcomp6 implementieren die IPComp-Nutzdatenkomprimierung und können im Rahmen einer IPsec-SA automatisch ausgehandelt werden, auch wenn sie nicht explizit konfiguriert sind. Setzen Sie keines davon auf einem VPN-Gateway, IPsec-Endpunkt oder irgendwo, wo ip xfrm policy Regeln zurückgibt, auf die Blacklist. Beachten Sie, dass das Framework-Modul xfrm_algo absichtlich nicht in dieser Liste enthalten ist – gemäß den Anleitungen der Hersteller (Red Hat, Ubuntu, AWS) reicht es aus, die ESP- und IPComp-Protokollmodule sowie die Netlink-Konfigurationsschnittstelle xfrm_user zu blockieren, und das Blacklisten von xfrm_algo würde jede andere xfrm-Transformation ohne zusätzlichen Nutzen zerstören.
• Die RxRPC-Module (rxrpc, kafs) werden für jeden Host benötigt, der AFS-Dateisysteme einbindet. Das Deaktivieren wird diese Mounts beim nächsten Neustart zerstören.
• algif_aead macht Kernel-Kryptografie über die AF_ALG-Socket-Familie verfügbar. Es wird selten direkt von Anwendungscode verwendet; überprüfen Sie dies jedoch durch Auflisten der Live-Sockets (ss -p --af-alg) und der Userspace-Konsumenten, bevor Sie es auf die Blacklist setzen.

Die von vcheck geschriebenen Blacklist-Snippets werden erst zum Zeitpunkt des Modulladens wirksam (normalerweise beim nächsten Neustart oder durch modprobe -r <module>, während das System im Leerlauf ist). Ein Modul, das bereits geladen ist, läuft auch nach -fix weiter – vcheck meldet dies als blacklisted but currently loaded; run 'modprobe -r' or reboot. Durch Hinzufügen von -unload zu -fix wird vcheck angewiesen, nach dem Schreiben der Blacklist-Snippets modprobe -r für geladene betroffene Module auszuführen. Verwenden Sie dies nur, wenn Sie bestätigt haben, dass die Module sicher aus dem laufenden Kernel entfernt werden können.

Wenn Sie -rebuild-initramfs mit -fix übergeben, wird die Initramfs nur für den derzeit laufenden Kernel neu generiert (update-initramfs -u -k $(uname -r) unter Debian/Ubuntu, dracut -f --kver $(uname -r) unter RHEL/Fedora). Andere installierte Kernel behalten ihre vorhandene Initramfs unberührt, sodass Sie nach einem Neustart bei Problemen einen älteren Kernel-Eintrag aus dem Boot-Menü auswählen und das System wiederherstellen können. Zukünftige Kernel-Installationen bauen ihre eigene Initramfs aus dem aktuellen Zustand von /etc/modprobe.d/ neu auf, sodass die Blacklist automatisch propagiert wird, ohne vcheck erneut ausführen zu müssen. Wenn weder update-initramfs noch dracut vorhanden sind (z. B. Arch, Alpine, unveränderliche Images), warnt vcheck und fährt fort – bauen Sie die Initramfs vor dem Neustart manuell mit dem Tool Ihrer Distribution neu auf.

Der Neubau kann mehrere Minuten dauern (insbesondere dracut auf Hosts mit vielen Treibern), was das diagnostische -command-timeout überschreiten würde. Er läuft unter seinem eigenen -initramfs-timeout (Standard 10m), sodass der Neubau den benötigten Spielraum erhält, während die schnellen Prüfungen ihr knappes Budget behalten. Erhöhen Sie -initramfs-timeout für langsame Hardware, oder übergeben Sie 0, um das Timeout vollständig zu deaktivieren. Während langlebiger Remote-Befehle sendet vcheck standardmäßig alle 30s SSH-Keepalive-Anfragen, um zu verhindern, dass NAT/Firewall-Idle-Timer die Verbindung trennen. Passen Sie dies mit -ssh-keepalive an, oder übergeben Sie 0, um es zu deaktivieren.

Installation

Homebrew (macOS):

brew install --cask krisiasty/tap/vcheck

Vorkompilierte Binärdateien für Linux, macOS und Windows werden auf der Releases-Seite veröffentlicht.

Aus dem Quellcode (erfordert Go 1.26+):

go install github.com/krisiasty/vcheck@latest

Verwendung

vcheck -host HOST [flags]