Eine Sicherheitslücke im CIFSwitch-Linux-Kernel ermöglicht lokalen Root-Zugriff auf cifs-utils

28. Mai 2026 – 7 Minuten Lesezeit Chris DeMars, Senior Developer Advocate

Die Kurzfassung

Was: Eine neue Schwachstelle zur lokalen Rechteausweitung unter Linux namens „CIFSwitch“ nutzt eine fehlende kernelseitige Überprüfung der Beschreibungen des Schlüssels „cifs.spnego“ in Verbindung mit dem Vertrauen, das der Userspace-Helper „cifs.upcall“ diesen Beschreibungen entgegenbringt. Das Ergebnis ist eine Root-Shell, die von jedem nicht privilegierten lokalen Konto auf betroffenen Hosts aus aufgerufen werden kann. Der betreffende Kernel-Codepfad ist seit 2007 vorhanden. Zum Zeitpunkt der Veröffentlichung wurde noch keine CVE-Nummer vergeben.

Auswirkung: Ein öffentlicher Proof-of-Concept von Asim Manizada bietet jedem lokalen Benutzer ohne Sonderrechte einen zuverlässigen Weg zum Root-Zugriff auf Systemen, die die Voraussetzungen für den Exploit erfüllen. Der Autor bestätigte, dass rund 30 Kombinationen aus Distributionen und Editionen betroffen sind.

Status: Manizada hat CIFSwitch am 28. Mai 2026 auf oss-security veröffentlicht , nachdem eine Sperrfrist für Linux-Distributionen abgelaufen war. Der Fehler wurde den Kernel-/CIFS-Betreuern am 16. Mai gemeldet, und der Upstream-Fix (Commit 3da1fdf4efbc) ist seit über einer Woche öffentlich und steht für die stabile Version in der Warteschlange.

Schweregrad: Bestätigt in der Standardkonfiguration unter AlmaLinux 9.7, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint 21/22, Kali 2021 bis 2026 (Headless) und SLES 15 SP7/SAP. Anfällig, wenn cifs-utils manuell auf Debian 11/12/13, Ubuntu 18/20/22/24.04, openSUSE Leap 15.6, Oracle Linux 8/9 und Amazon Linux 2023 installiert wird.

Warum dies wichtig ist: Der Exploit zielt auf einen standardmäßig installierten privilegierten Hilfsprozess ab, benötigt lediglich eine nicht privilegierte lokale Shell und verfügt über einen funktionierenden öffentlichen PoC. Jeder Linux-Host, auf dem ein Angreifer ohne Privilegien Code ausführen kann, sollte als unmittelbar gefährdet betrachtet werden, wenn cifs-utils und die standardmäßige cifs.spnego-Regel vorhanden sind, das CIFS-Kernelmodul verfügbar ist, Namespaces ohne Privilegien aktiviert sind und die LSM-Richtlinie den Pivot nicht blockiert.

Gehen Sie wie folgt vor: Falls Ihr Host keine Kerberos-authentifizierten SMB-Freigaben einbindet (was bei den meisten Servern der Fall ist), überschreiben oder entfernen Sie die Standardregel „cifs.spnego request-key“. Wenn Sie keine rootless-Container oder „unprivileged unshare“ benötigen, deaktivieren Sie stattdessen die „unprivileged user namespaces“. Die entsprechenden Befehle und die damit verbundenen Vor- und Nachteile finden Sie weiter unten.

Die Langfassung

Asim Manizada machte CIFSwitch am 28. Mai 2026 auf der oss-security-Mailingliste bekannt, dem Tag, an dem die mit den Linux-Distributionen vereinbarte Sperrfrist ablief. Der ursprüngliche Bericht wurde den Kernel-Betreuern bereits am 16. Mai übermittelt. Der Upstream-Fix ist seit über einer Woche öffentlich zugänglich und steht für die Stable-Version auf der Warteliste. Die Downstream-Distributionen übernehmen ihn derzeit nach und nach.

Das Kernel-Problem geht auf den Commit f1d662a aus dem Jahr 2007 zurück, mit dem der Schlüsseltyp „cifs.spnego“ ohne einen Hook zur Validierung der Beschreibung hinzugefügt wurde. Die Schwachstelle blieb 19 Jahre lang unentdeckt, da die praktische Exploit-Kette von zwei späteren Ergänzungen abhängt: den Namespaces für nicht privilegierte Benutzer in Linux v3.8 (2013) und der Logik zum Wechseln der Namespaces in cifs-utils (nominal gilt dies für Version 6.14 und höher, doch Backports anderer CVE-Korrekturen haben auch in älteren cifs-utils Probleme verursacht). Ohne alle drei Komponenten an einem Ort läuft die Kette nicht durchgängig.

Manizada schreibt in seinem Bericht ganz offen, dass der Fehler mithilfe von LLM-gestütztem Graphen-Reasoning in Bezug auf Kernel-Objekte, Sicherheitseigenschaften und die Grenzen, an denen diese Objekte zwischen Kernel und Userspace wechseln, entdeckt wurde. Die Entdeckungsmethode ist an sich schon interessant. Vorerst ist jedoch die dringlichere Frage, was der Fehler bewirkt und wie man ihn beheben kann.

So funktioniert der Exploit

Der Exploit besteht aus vier Komponenten: einer Linux-Kernel-Funktion namens „keyrings“, einem Userspace-Hilfsprogramm namens „cifs.upcall“, Linux-Benutzernamensräumen und dem Name Service Switch (NSS). Jede dieser Komponenten ist Teil der normalen Infrastruktur und erfüllt ihre Aufgabe. Der Fehler besteht darin, dass eine Vertrauensgrenze zwischen Kernel und Userspace nie durchgesetzt wurde, und der Rest der Exploit-Kette ergibt sich daraus.

Schritt 1: Kernel-Schlüsselbunde und der Schlüsseltyp „cifs.spnego“

Linux-Schlüsselringe sind ein Kernel-Subsystem, das Authentifizierungsdaten wie Kerberos-Tickets und Verschlüsselungsschlüssel speichert. Wenn der Kernel einen Schlüssel benötigt, über den er nicht verfügt, fordert er den Userspace über einen Callout-Mechanismus auf, einen solchen zu generieren. Eine Regel in /etc/request-key.d/ besagt: „Um einen Schlüssel dieses Typs zu generieren, führe diesen Helper als Root aus.“ Für SMB- oder CIFS-Mounts, die Kerberos verwenden, lautet der Schlüsseltyp cifs.spnego und das Standard-Hilfsprogramm ist /usr/sbin/cifs.upcall, das im Paket cifs-utils enthalten ist.

Wenn der Kernel nach einem cifs.spnego-Schlüssel fragt, erstellt er eine Beschreibungszeichenfolge, die berechtigungsrelevante Felder enthält: die Benutzer-ID für die Einbindung, die UID der Anmeldeinformationen, die Prozess-ID und den Ziel-Namespace. Diese Zeichenfolge soll vom Kernel stammen. Der Hilfsprozess im Userspace vertraut diesen Feldern und nutzt sie, um zu entscheiden, welche Anmeldeinformationen abgerufen werden sollen und in welchem Namespace er agieren soll.

Schritt 2: Überprüfung auf fehlenden Kernel

Der Userspace kann den Systemaufruf `request_key()` direkt aufrufen und einen `cifs.spnego`-Schlüssel mit einer beliebigen Beschreibung anfordern. Vor dem Patch fehlte in der Kernel-Definition von `cifs_spnego_key_type` der Hook `.vet_description`, der dem Schlüsselbund-Subsystem mitteilt, „nur Beschreibungen von einer bestimmten Quelle zu akzeptieren“. Ohne diesen Hook kann jeder nicht privilegierte Prozess einen cifs.spnego-Schlüssel mit einer gefälschten Beschreibung anfordern, und das Schlüsselbund-Subsystem startet cifs.upcall als Root mit der Beschreibung des Angreifers.

Ein Detail, das es wert ist, gleich zu Beginn aus Manizadas Bericht hervorzuheben: Der Kernel muss nicht unbedingt einen Schlüssel zurückgeben, damit „cifs.upcall“ gestartet werden kann. Der Helper wird zuerst ausgeführt. Bis der Kernel den Schlüssel als ungültig zurückweist, hat der Root-Helper bereits das getan, was der Angreifer beabsichtigt hat. Genau das macht den oben erwähnten fehlenden Validierungs-Hook so folgenschwer.

Schritt 3: Wechsel des Namespace innerhalb des Root-Helpers

cifs.upcall parses the description, finds upcall_target=app and pid=<some-pid>, and calls setns() to switch into the namespaces of the supplied pid. This is a deliberate feature, intended to make cifs.upcall resolve names against the right filesystem and network view when serving containerized mounts. The problem is that the kernel has just been tricked into trusting an attacker’s pid as if it came from a real kernel-side CIFS operation.

Schritt 4: NSS als Primitive zum Laden von Code

Bevor die Root-Rechte abgelegt werden, führt cifs.upcall eine Kontenabfrage mit getpwuid() durch. Unter Linux laufen Kontenabfragen über den Name Service Switch (NSS), ein in /etc/nsswitch.conf konfiguriertes, erweiterbares System, das für jeden Abfragetyp entscheidet, welche gemeinsam genutzten Bibliotheken geladen werden sollen. Da sich cifs.upcall nun im Mount-Namespace des Angreifers befindet, liest es die nsswitch.conf des Angreifers, und das geladene NSS-Modul ist eine vom Angreifer kontrollierte libnss_*.so.2. Dieses gemeinsam genutzte Objekt läuft als Root innerhalb des Helpers.

Schritt 5: Dauerhafte Speicherung über sudo

Das NSS-Modul des öffentlichen PoC schreibt eine Datei unter /etc/sudoers.d/, die dem Angreifer die Berechtigung „NOPASSWD: ALL“ gewährt. Nachdem der Helper beendet wurde, verlässt der Angreifer den Namespace und führt „sudo“ aus. Die Shell läuft als Root. Die auf der Festplatte gespeicherte Binärdatei von „cifs.upcall“ bleibt unberührt; der Missbrauch findet im laufenden Helper-Prozess und im vom Angreifer kontrollierten Namespace statt.

Die Korrektur ist geringfügig. Der Upstream-Patch fügt eine vierzeilige Funktion namens `cifs_spnego_key_vet_description()` hinzu, die `current_cred()` mit dem privaten `spnego_cred` des Kernels vergleicht. Stimmen diese nicht überein, wird die Schlüsselanforderung mit dem Fehlercode -EPERM abgelehnt. Nur der kerneleigene CIFS-Codepfad darf einen Schlüssel dieses Typs instanziieren. Das reicht aus, um die Kette in Schritt 2 zu stoppen.

Wer ist betroffen?

Der anfällige Codezweig von „cifs.spnego“ stammt aus dem Jahr 2007, doch die öffentlich bekannte Exploit-Kette ist praktisch nur auf Systemen mit Unterstützung für nicht privilegierte Benutzernamensräume aus der Linux-Version 3.8 und den übrigen erforderlichen Voraussetzungen nutzbar. Ob die Exploit-Kette auf einem bestimmten Host funktioniert, hängt von drei nachgelagerten Bedingungen ab: ob cifs-utils installiert ist, ob nicht privilegierte Benutzernamensräume aktiviert sind und ob die LSM-Richtlinie des Hosts (SELinux oder AppArmor) einen Schritt in der Kette blockiert.

Standardmäßig ausnutzbar (cifs-utils vorinstalliert, Namespaces ohne Sonderrechte aktiviert, die Standard-LSM-Richtlinie lässt die Kette zu): AlmaLinux 9.7 Workstation und das Azure-Cloud-Image, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint Cinnamon 21.3 und 22.3, Kali Linux 2021.4 bis 2026.1 (headless), SLES 15 SP7, SLES SAP 15 SP7 und SLES SAP 16.

Dies wurde auch intern von KernelCare für CloudLinux 10 bestätigt. CL wird über seine „tuned“-Profile mit deaktiviertem SELinux ausgeliefert, sodass die SELinux-Ausnahmeregelung, die RHEL 10, AlmaLinux 10, Rocky Linux 10 und Oracle Linux 10 schützt, für CloudLinux 10 nicht gilt.

Ausnutzbar, wenn cifs-utils manuell installiert wurde: Ubuntu 18.04, 20.04, 22.04 und 24.04 Desktop und Server (24.04 erfordert zusätzlich den öffentlich dokumentierten „aa-exec -p trinity“-Trick, um die AppArmor-Benutzerrichtlinie zu umgehen); Pop!_OS 22.04 und 24.04; Debian 11, 12 und 13; CentOS Stream 9 Cinnamon/KDE/MATE/XFCE; Rocky Linux 9 KDE und Workstation-Lite; openSUSE Leap 15.6; Rocky Linux 8 GenericCloud; Oracle Linux 8 und 9 KVM; Amazon Linux 2023 KVM.

Durch Standardrichtlinien blockiert, aber darunter anfällig: Die meisten EL10-Distributionen (RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10) blockieren den Namespace-Pivot „cifs.upcall“ unter SELinux-Enforcing. Ubuntu 26.04 blockiert die Kette unter seiner standardmäßigen AppArmor-userns-Richtlinie. Fedora 40 bis 44 und CentOS Stream 10 blockieren dies ebenfalls standardmäßig. Diese Hosts werden angreifbar, wenn der Betreiber „setenforce 0“ ausführt oder die AppArmor-userns-Sysctls lockert.

Nicht öffentlich ausnutzbar (PoC): Amazon Linux 2, das cifs-utils 6.2 enthält und aus einer Zeit vor der Einführung der Namespace-Switching-Logik stammt. CentOS 7 und RHEL 7, bei denen standardmäßig user.max_user_namespaces = 0 gesetzt ist. Kali Linux 2019.4 und 2020.4 mit der älteren Version cifs-utils 6.9.

Die Sicherheitslücke hängt letztlich von drei Faktoren ab: ob „cifs.upcall“ verfügbar ist, ob nicht privilegierte Benutzer zugelassen sind und ob die LSM-Richtlinie den Namespace-Pivot blockiert. Überprüfen Sie dies mit den Befehlen im nächsten Abschnitt.

Jetzt Maßnahmen ergreifen

Die Kette umfasst zwei Voraussetzungen, von denen jede eine klare Abmilderung bietet. Wählen Sie diejenige, deren Vor- und Nachteile zu Ihrer Arbeitslast passen.

Empfehlung: Überschreiben Sie die Standardregel für den CIFS-SPNEGO-Anforderungsschlüssel

Wenn der Host keine Kerberos-authentifizierten SMB-Freigaben einbindet (was bei den meisten Servern der Fall ist), wird die Standardregel für den „cifs.spnego“-Anforderungsschlüssel nicht verwendet. Durch das Überschreiben dieser Regel wird die Kette bereits in Schritt 1 unterbrochen. NTLM-/passwortbasierte SMB-Client-Einbindungen sind in der Regel nicht vom Kerberos-SPNEGO-Upcall abhängig; überprüfen Sie jedoch Ihre Einbindungsoptionen, bevor Sie die Regel entfernen.

echo 'create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S' | sudo tee /etc/request-key.d/cifs.spnego.conf

Passen Sie den Pfad zu „keyctl“ an, falls Ihre Distribution das Programm an einem anderen Ort ablegt. Dies entspricht der vom Autor empfohlenen Umgehungslösung und lehnt die Schlüsselanforderung sauber ab, anstatt sie über ein Programm, das nicht zum Schlüsselbund gehört, fehlschlagen zu lassen.

Wenn Sie SMB überhaupt nicht verwenden, löschen Sie die Datei vollständig:

sudo rm /etc/request-key.d/cifs.spnego.conf

Wenden Sie dies nicht auf Hosts an, die Kerberos-authentifizierte SMB-Freigaben einbinden. cifs.upcall ist genau der SPNEGO-Ticket-Helper, auf den diese Einbindungen angewiesen sind.

Setzen Sie die Einstellungen nach der Installation des Patches zurück, indem Sie cifs-utils neu installieren (wodurch die Standardregel wiederhergestellt wird) oder Ihre Überlagerungsdatei entfernen.

Alternative: Nicht privilegierte Benutzernamensräume deaktivieren

Der PoC muss einen privaten Benutzer und einen Mount-Namespace angeben, bevor er den Upcall auslöst. Das Blockieren nicht privilegierter Benutzer führt zum Abbruch der Kette, unabhängig vom Status von cifs-utils.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

Hinweis zur Kompatibilität: Nicht privilegierte Benutzernamensräume werden von rootless-Container-Laufzeitumgebungen (rootless Podman, rootless Docker, bwrap-basierte Flatpaks), verschiedenen CI-Sandboxen, dem nicht privilegierten unshare(1) und der Chromium-Sandbox benötigt. Auf Host-Workloads akzeptabel, auf Entwickler- oder Container-Hosts störend.

Alternative: Deinstallieren Sie cifs-utils, wenn kein SMB-Client verwendet wird

Die meisten Serverflotten benötigen es nicht. Durch das Entfernen des Pakets werden sowohl „cifs.upcall“ als auch die Standardregel für den Anforderungsschlüssel entfernt.

# Debian / Ubuntu
sudo apt remove cifs-utils

# RHEL / AlmaLinux / Rocky / Oracle / CentOS Stream
sudo dnf remove cifs-utils

Überprüfen Sie, ob Ihr Host angreifbar ist

# Is cifs-utils installed?
command -v cifs.upcall && (rpm -q cifs-utils 2>/dev/null || dpkg -l cifs-utils 2>/dev/null)

# Is the default cifs.spnego request-key rule present?
cat /etc/request-key.d/cifs.spnego.conf 2>/dev/null

# Are unprivileged user namespaces enabled?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

Ein Host ist nur dann ein gültiges Ziel, wenn „cifs.upcall“ installiert ist, eine „cifs.spnego“-Regel für Anforderungsschlüssel vorhanden ist und nicht privilegierte Benutzer zugelassen sind.

KernelCare Rebootless Patch

Stand: 29.05.2026, 14:00 Uhr UTC: Patches für EL8 ohne Neustart wurden im Haupt-Feed bereitgestellt. Patches für AlmaLinux 9 wurden ebenfalls im Haupt-Feed bereitgestellt. Patches ohne Neustart für die übrigen EL9-Varianten, EL10, Oracle Linux UEK-Kernel (UEK6 und UEK7), Ubuntu, Debian und Proxmox VE wurden im Test-Feed bereitgestellt.

Sobald die Funktion im Test-Feed verfügbar ist, befolgen Sie die nachstehenden Anweisungen, um sie zu nutzen:

kcarectl --update --prefix test

Nach der Validierung wird der Patch beim nächsten geplanten Durchlauf bereitgestellt, oder Sie können ihn bei Bedarf abrufen:

kcarectl --update

Überprüfen Sie, ob der Patch angewendet wurde. Der Patch wird ohne CVE-ID bereitgestellt und ist anhand seiner Beschreibung im Upstream-Code zu identifizieren:

kcarectl --patch-info | grep 'cifs.spnego'
# expected: kpatch-description: smb: client: reject userspace cifs.spnego descriptions (cifs LPE)

Sobald eine CVE-Nummer vergeben wurde, lässt sich diese mit dem Befehl „kcarectl –patch-info | grep CVE-2026-“ anzeigen.

Was man im weiteren Verlauf im Auge behalten sollte

Die Zuweisung einer CVE-Kennung steht noch aus. Kernel-Updates von Red Hat, Ubuntu, Debian, SUSE, Oracle und Amazon werden nach und nach bereitgestellt, sobald die nachgelagerten Projekte den in der Warteschlange befindlichen stabilen Backport übernehmen.

Wir werden diesen Beitrag fortlaufend aktualisieren, sobald die Patches ohne Neustart veröffentlicht und die CVE-Nummern vergeben werden.

Jeden Kernel patchen, kein Neustart erforderlich

Wenn Sie noch kein KernelCare-Nutzer sind, ist jetzt ein guter Zeitpunkt, um zu erfahren, wie Patches ohne Neustart kritische Linux-Systeme schützen können, ohne dass Notfallwartungsfenster oder Ausfallzeiten erforderlich sind.

Erfahren Sie hier mehr über KernelCare →

Zusammenfassung

Artikel Name

Eine Sicherheitslücke im CIFSwitch-Linux-Kernel ermöglicht lokale Root-Rechte

Beschreibung

CIFSwitch ist eine Schwachstelle zur Ausweitung lokaler Berechtigungen unter Linux, die auf Systemen, die cifs-utils, Benutzernamensräume und eine anfällige CIFS-SPNEGO-Verarbeitung nutzen, Root-Rechte gewähren kann.

Autor

Chris DeMars

Name des Herausgebers

TuxCare

Logo des Herausgebers