CVE-2026-23111 Defensives Validierungsskript

Übersicht

CVE-2026-23111 ist eine Schwachstelle im Linux-Kernel in nf_tables, die von einem unprivilegierten Benutzer zur lokalen Privilegienausweitung auf Systemen ausgenutzt werden kann, auf denen Benutzer-Namespaces und nftables verfügbar sind.[1][2] Öffentliche Sicherheitsempfehlungen von Herstellern und Behörden beschreiben sie als lokales Problem, das Linux-Distributionen betrifft, und betonen das Patchen als primäre Lösung.[3][4]

Dieses Repository enthält ein defensives Validierungsskript, das dabei helfen soll zu bewerten, ob ein Host die mit dieser CVE verbundenen technischen Bedingungen aufweist, ohne einen Privilege-Escalation-Exploit bereitzustellen. Es prüft relevante Kernel- und Laufzeitbedingungen, lädt optional das Modul nf_tables für vollständige Funktionstests, versucht einen kontrollierten nicht-privilegierten Validierungspfad mit unshare und nft, sammelt lokale Diagnose-Traces und klassifiziert den Host in operative Bewertungen wie „wahrscheinlich sicher“, „durch lokale Richtlinie blockiert“ oder „exponierter Pfad verfügbar“.[1][5]

Was die CVE ist

Laut NVD ist CVE-2026-23111 eine Schwachstelle im Linux-Kernel in nf_tables, die als Logikfehler-Behebung in netfilter gelöst wurde und auf betroffenen Konfigurationen von einem unprivilegierten Benutzer über Benutzer-Namespaces und nftables zur lokalen Privilegienausweitung ausgenutzt werden kann.[1] Ubuntus Sicherheitshinweis beschreibt denselben übergeordneten Ausnutzungspfad und verfolgt betroffene und behobene Paketzustände je Release.[2]

Red Hat gibt an, dass ein lokaler Benutzer mit niedrigen Privilegien das Problem ausnutzen kann, um einen Denial of Service zu verursachen oder möglicherweise eine Privilegienausweitung zu erreichen, und dokumentiert einen Minderungspfad, der darauf basiert, das Laden des Moduls nf_tables zu verhindern, wenn dies betrieblich akzeptabel ist.[3] Auch die nationale Beratung des Canadian Centre for Cyber Security verweist betroffene Organisationen auf Hersteller-Updates und erwähnt die Regenerierung von initramfs, wenn Minderungsmaßnahmen zur Modul-Blockierung verwendet werden.[4]

Was das Skript tut

Das Skript ist für die defensive Expositionsbewertung gedacht, nicht für die Ausnutzung. Es wurde entwickelt, um:

• den laufenden Kernel, die Distributionsfamilie und relevante Laufzeit-Härtungseinstellungen zu identifizieren.
• zu prüfen, ob CONFIG_USER_NS und CONFIG_NF_TABLES vorhanden zu sein scheinen.[1]
• kernel.unprivileged_userns_clone und user.max_user_namespaces zu untersuchen, um abzuschätzen, ob unprivilegierte Benutzer-Namespaces verfügbar sind.
• zu erkennen, ob eine harte Modprobe-Verweigerung (install nf_tables /bin/false) oder eine schwache Blacklist für das Modul nf_tables vorhanden ist.
• das RPM-Changelog des Hersteller-Kernels auf einen CVE-2026-23111-Backport-Eintrag zu prüfen (nur RHEL-Familie).
• vor jeder Modul-Interaktion /proc/kallsyms auf das anfällige Symbol (nft_map_catchall_activate) gegenüber dem Symbol nach dem Patch (nft_catchall_set_activate) zu prüfen.
• optional nf_tables über modprobe zu laden, wenn --allow-load-module angegeben ist (siehe unten), und es beim Beenden automatisch zu entladen.
• einen eingeschränkten Validierungsschritt mit unshare -U -n --map-root-user + nft auszuführen, wenn das Modul geladen ist, und stdout, stderr sowie aktuelle Kernel-Logs aufzuzeichnen.
• zu verifizieren, dass unshare --user tatsächlich einen Namespace erstellt und dass CAP_NET_ADMIN darin funktionsfähig ist, um zu bestätigen, ob AppArmor- oder SELinux-Einschränkungen tatsächlich wirksam sind.
• hervorzuheben, ob lokale Sicherheitskontrollen wie AppArmor oder SELinux den getesteten Pfad zu blockieren scheinen.[6]
• bewertungsorientierte Ausgabe mit optionaler Farbhervorhebung für eine einfachere Sichtung auszugeben.

Das Skript speichert Logs in einem Unterverzeichnis des Skriptverzeichnisses und entfernt sie standardmäßig, sofern nicht --keep-logs verwendet wird.

Richtlinie zum Laden von Modulen

Standardmäßig lädt das Skript niemals nf_tables. Wenn das Modul beim Start des Skripts nicht bereits geladen ist, werden alle funktionalen nft-Tests übersprungen und die Bewertung wird ausschließlich aus Kernelversion, kallsyms-Fingerprint, Modprobe-Konfiguration, RPM-Changelog und Sysctl/LSM-Richtlinienhinweisen abgeleitet.

Diese konservative Standardeinstellung vermeidet eine unbeabsichtigte Erweiterung der Angriffsfläche auf Produktionssystemen. Um vollständige Funktionstests auf einem kontrollierten oder instrumentierten System zu ermöglichen, verwenden Sie --allow-load-module als root (siehe unten).

Verwendung

# Default — no module loading, policy-evidence-only verdict
./check_cve_2026_23111.sh
./check_cve_2026_23111.sh --color
./check_cve_2026_23111.sh --keep-logs
./check_cve_2026_23111.sh --color --keep-logs

# Full functional test — loads (and unloads) nf_tables, requires root
sudo ./check_cve_2026_23111.sh --allow-load-module
sudo ./check_cve_2026_23111.sh --allow-load-module --color --keep-logs

Optionen

Option	Beschreibung
--allow-load-module	Autorisiert das Skript, nf_tables über modprobe zu laden, falls das Modul nicht bereits geladen ist. Aktiviert den vollständigen nft-Catchall-Pfad-Test und den CAP_NET_ADMIN-Wirksamkeitstest. Das Modul wird beim Beenden automatisch entladen. Erfordert root. Wird verweigert, wenn bereits eine harte Modprobe-Verweigerung vorhanden ist. Nur auf Nicht-Produktions- oder instrumentierten Systemen verwenden.
--color	Aktiviert farbige stdout-Ausgabe, wenn das Terminal dies unterstützt.
--keep-logs	Behält Logs und Traces im Skriptverzeichnis, anstatt sie beim Beenden zu löschen.
--help	Zeigt Nutzungshinweise an und beendet das Skript.

Wann --allow-load-module verwendet werden sollte

Verwenden Sie --allow-load-module, wenn Sie die Bewertung mit der höchsten Aussagekraft auf einer isolierten, nicht für die Produktion bestimmten oder zweckgebauten Test-VM benötigen. Typische Szenarien:

• Ein Kernel im anfälligen Bereich wird validiert, bevor der Hersteller-Fix bereitgestellt wird.
• Das Testsystem hat KASAN oder andere Instrumentierung aktiviert, und Sie möchten Kernel-Traces beobachten.
• Das Modul wird auf dem Zielhost nicht verwendet, und für Audit-Nachweise ist eine vollständige Ende-zu-Ende-Pfadprüfung erforderlich.

Verwenden Sie --allow-load-module nicht auf Produktionshosts, auf denen nf_tables absichtlich blockiert ist oder wo das Laden gegen eine Härtungsrichtlinie verstoßen würde.

Sicherheitsprüfungen für --allow-load-module

Vor dem Versuch, das Modul zu laden, erzwingt das Skript die folgenden Prüfungen und beendet sich mit einem Fehler, wenn eine davon fehlschlägt:

1. Eine harte Modprobe-Verweigerung (install nf_tables /bin/false) darf nicht in /etc/modprobe.d/ vorhanden sein.
2. modprobe muss auf dem System verfügbar sein.
3. Das Skript muss als root (uid 0) ausgeführt werden.

Wenn das Modul vom Skript erfolgreich geladen wurde, wird beim Beenden modprobe -r nf_tables über den cleanup()-Trap aufgerufen, unabhängig davon, wie das Skript endet (Erfolg, Fehler oder CTRL+C).

Bewertungsmodell

Das Skript verwendet operative Bewertungen anstelle von Exploit-Ergebnissen: