haydenjames/cve-2026-31431-checkSchreibgeschützter Checker für CVE-2026-31431 (algif_aead lokaler Root). Meldet den Kernel-/Modulstatus und schlägt Gegenmaßnahmen vor.
Nur-Lese-Prüfer für die algif_aead-Local-Root-Sicherheitslücke (CVE-2026-31431).
Untersucht die Kernel-Konfiguration, den Modulstatus, die Erreichbarkeit von AF_ALG-Sockets und alle von dir eingerichteten
Gegenmaßnahmen und gibt dann ein Urteil aus. Er führt keinen Exploit-Code aus.
Begleitprojekt zu dirty-frag-check (CVE-2026-43284 / CVE-2026-43500).
Achtung: Dies ist eine Heuristik. Ein grünes Urteil ist keine Garantie. Gleiche es mit dem Advisory deiner Distribution ab, bevor du einen Host als sicher einstufst. MIT, ohne Gewähr.
curl -fsSL https://github.com/haydenjames/CVE-2026-31431-check/releases/latest/download/cve-2026-31431.sh | bash
Lies es zuerst, wenn du dem Pipe-to-bash nicht vertraust:
curl -fsSLO https://github.com/haydenjames/CVE-2026-31431-check/releases/latest/download/cve-2026-31431.sh
less cve-2026-31431.sh
chmod +x cve-2026-31431.sh && ./cve-2026-31431.sh
Für Änderungskontrolle auf ein Release-Tag pinnen: https://raw.githubusercontent.com/haydenjames/CVE-2026-31431-check/v1.0.3/cve-2026-31431.sh.
-q für einzeilige Fleet-Ausgabe. -h für Hilfe. Exit 0 ok, 1 verwundbar, 2 unbekannt.
-q gibt eine Zeile pro Host aus, sodass du es durch jeden Remote-Runner
leiten kannst, den du bereits verwendest:
# parallel-ssh
parallel-ssh -h hosts.txt -i 'bash -s -- -q' < cve-2026-31431.sh
# ansible
ansible all -m script -a "cve-2026-31431.sh -q"
Exit-Codes (0 ok, 1 verwundbar, 2 unbekannt) funktionieren ebenfalls, wenn dein Tooling nach Status aggregiert.
bash 4+ sowie die üblichen awk/grep/sed/lsmod/modprobe. Wenn python3
vorhanden ist, wird zusätzlich die Erreichbarkeit von AF_ALG-Sockets getestet; andernfalls wird diese Prüfung
übersprungen. Die Prüfung selbst benötigt kein Root. Das Anwenden der Gegenmaßnahme schon.
algif_aead-Status. Eingebaut, ladbares Modul, geladen oder fehlend. Liest
/boot/config-* oder /proc/config.gz und fällt auf lsmod zurück.
1b. authencesn-Status. Laut Upstream-Advisory ist dies das Modul,
das den Fehler tatsächlich enthält — algif_aead ist nur ein Zugriffspfad,
IPsec ein anderer. Wird über lsmod/modinfo und die Konfiguration erkannt.modprobe -n -v, dass die Blacklist tatsächlich greift. Markiert außerdem
den fehlerhaften DefaultRestrictAddressFamilies-systemd-[Manager]-Trick,
der die Runde macht — diese Direktive wirkt nur bei Units und nicht
in system.conf.d. Meldet den SELinux- und AppArmor-Status.algif_aead ist eingebaut. Best-Effort-Urteil; es stützt sich auf die Exit-Codes von dnf check-update, die aus unzusammenhängenden Gründen (Netzwerk, veraltete Metadaten) ungleich null sein können. Geh nicht davon aus, dass du nur warten musst, ohne deinen Distributionstracker zu prüfen.Laut Upstream-Advisory
liegt der Fehler tatsächlich im Krypto-Modul authencesn — algif_aead ist
nur einer der Zugriffspfade. Blackliste beide zur Sicherheit:
sudo tee /etc/modprobe.d/disable-cve-2026-31431.conf <<'EOF'
install algif_aead /bin/false
install authencesn /bin/false
EOF
sudo rmmod authencesn algif_aead 2>/dev/null || true
Wenn rmmod "module is in use" meldet, nutzt etwas auf dem System aktiv
AF_ALG oder IPsec (manche VPNs, Festplattenverschlüsselung, Krypto-Userspace-Tools).
Erzwinge das Entladen nicht. Patchen und neu starten.
Wenn der verwundbare Code in deinen Kernel einkompiliert ist, hilft die Blacklist nicht. Nur ein Kernel-Update behebt das.
AlmaLinux 8, AlmaLinux 9.7, CentOS 7 (TuxCare ELS), Ubuntu 22.04, Ubuntu 24.04.
Fehlerberichte, die v1.0.1 geprägt haben:
kmod-Blacklist-Update nicht erkannt wurde, was zu falschen VULNERABLE-Urteilen auf gepatchten Ubuntu-Hosts führte.MIT — siehe LICENSE.