Überblick: Was CVE-2026-31718 angreifbar macht
Die Schwachstelle CVE-2026-31718 betrifft den im Linux-Kernel integrierten SMB-Server ksmbd. Laut NVD-Eintrag handelt es sich um einen Use-After-Free-Fehler in der Funktion __ksmbd_close_fd(), der durch ein asymmetrisches Cleanup beim Schließen von Datei-Handles ausgelöst wird. Der ENISA-Eintrag EUVD-2026-26527 verweist auf denselben Sachverhalt und ordnet die Schwachstelle der CWE-Kategorie CWE-416 (Use After Free) zu.
Auslöser ist ein Verhalten rund um sogenannte durable file handles: Bricht eine SMB-Session ab, bleibt das zugehörige Datei-Handle für einen begrenzten Zeitraum bestehen, damit ein Client transparent reconnecten kann. Genau in diesem Fenster bleibt der Kernel-Datenpfad inkonsistent — eine Konstellation, die ein Angreifer mit Netzwerkzugriff auf den SMB-Dienst ausnutzen kann.
- CVE-ID: CVE-2026-31718 (ENISA: EUVD-2026-26527)
- Komponente: Linux-Kernel, Subsystem
fs/smb/server(ksmbd) - Schwachstellentyp: CWE-416 Use-After-Free
- CVSS 3.1 Base Score: 9.8 (Critical), Vector
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Veröffentlicht: 1. Mai 2026 · Zuletzt geändert: 17. Mai 2026 (Quelle: kernel.org)
Aus Sicht des Defenders ist relevant, dass das CVSS-Vektorprofil netzwerkbasierte Ausnutzung ohne Authentifizierung und ohne Nutzerinteraktion beschreibt — eine Kombination, die typischerweise zur unmittelbaren Patch-Pflicht führt. Ob daraus in der Praxis Remote Code Execution wird, hängt von zusätzlichen Primitiven ab, die ein Angreifer aus dem korrupten Kernel-Heap aufbauen kann. Speicherkorruption im Kernel ist jedoch grundsätzlich als hochwertiger Exploit-Ausgangspunkt zu werten.
Technische Analyse: Asymmetrisches Cleanup zwischen zwei Pfaden
Die Wurzel der Schwachstelle liegt darin, dass zwei voneinander unabhängige Cleanup-Pfade denselben Zustand teilen, aber jeweils nur einen Teil davon konsistent zurücksetzen. Der Briefing-Stand fasst dies als „asymmetrische Cleanup-Logik“ zusammen — im NVD-Eintrag wird dieselbe Beschreibung in den technischen Details verwendet.
Beim regulären Disconnect ruft ksmbd session_fd_check() auf. Diese Routine setzt fp->conn = NULL, gibt die Connection-Struktur frei und entzieht so dem File-Pointer die Bindung an die Verbindung. Was dabei nicht passiert: Die Byte-Range-Locks, die in der Liste fp->lock_list hängen, werden nicht von der ursprünglichen conn->lock_list abgehängt. Ihre smb_lock->clist-Einträge zeigen weiter in einen bereits freigegebenen Speicherbereich.
Ablauf der Ausnutzung
- 1Client öffnet ein durable File-Handle über eine bestehende SMB-Session und setzt Byte-Range-Locks.
- 2Die Session bricht ab (Disconnect, Timeout oder gezielter TCP-Reset); session_fd_check() läuft an.
- 3session_fd_check() setzt fp->conn = NULL und gibt die Connection-Struktur frei – die Lock-Liste bleibt verwaist.
- 4Der Durable Scavenger Thread läuft nach Ablauf des Timeouts und versucht über conn->lock_list aufzuräumen.
- 5__ksmbd_close_fd() dereferenziert smb_lock->clist auf der bereits freigegebenen conn->lock_list – Use-After-Free.
- 6Im günstigsten Fall folgt ein Kernel-Crash (Denial-of-Service), im ungünstigen Fall eine kontrollierte Speicherkorruption.
Die Schwachstelle setzt voraus, dass ksmbd als SMB-Server aktiviert ist und für die betroffene Freigabe durable handles erlaubt sind. Klassische Linux-Distributionen verwenden in den meisten Setups weiterhin Samba (user-space). ksmbd wird typischerweise dort eingesetzt, wo SMB-Throughput im Kernel-Pfad besonders relevant ist — etwa bei NAS-Appliances, Hochleistungs-Fileservern oder Container-Storage-Backends.
Der NVD-Eintrag listet fünf Commits aus der kernel.org-History, die den Fehler über mehrere stabile Branches korrigieren. Die Patches synchronisieren die Cleanup-Pfade so, dass entweder die Locks vor der Freigabe der Connection-Struktur entfernt werden oder der Scavenger-Thread den null-gewordenen Pointer korrekt erkennt.
Betroffene Kernel-Versionen und Patch-Stand
Der NVD-Eintrag dokumentiert mehrere parallele Versionsbäume, die einen Fix erhalten haben. In der Praxis bedeutet das: Wer ksmbd nutzt, sollte den exakten Distributions-Kernel gegen die Fix-Linie abgleichen — nicht nur die obere Versionsnummer.
| Kernel-Zweig | Betroffene Versionsspanne | Status |
|---|---|---|
| 6.6.x (LTS) | ab 6.6.32 bis vor 6.7 | Fix in 6.6-stable-Linie verfügbar |
| 6.9 – 6.12.x | 6.9 bis vor 6.12.83 | Fix ab 6.12.83 |
| 6.13 – 6.18.x | 6.13 bis vor 6.18.24 | Fix ab 6.18.24 |
| 6.19 – 7.0.x | 6.19 bis vor 7.0.1 | Fix ab 7.0.1 |
| 7.1 | 7.1-rc1 | Fix in -rc-Folge eingespielt |
Diese Angaben stammen aus dem NVD-Eintrag zu CVE-2026-31718 (Quelle: kernel.org) sowie dem ENISA-Eintrag EUVD-2026-26527. Die Detailtiefe ist mittel: Der CVE-Text ist im NVD-Eintrag verkürzt vorhanden, der vollständige Patch-Text liegt in den verlinkten kernel.org-Commits. Sollten Distributionen abweichende Backports veröffentlichen, prüfen Sie ergänzend die Security-Advisories des jeweiligen Anbieters.
Ein schneller Versionscheck lässt sich auf einem laufenden System wie folgt durchführen:
# Kernel-Version und ksmbd-Status prüfen uname -r modinfo ksmbd 2>/dev/null | grep -E '^(filename|version|srcversion)' # Ist der Server aktiv und lauscht auf 445/TCP? ss -ltnp '( sport = :445 )' systemctl is-active ksmbd 2>/dev/null # Konfigurierte Shares und durable-handle-Optionen sichten test -f /etc/ksmbd/ksmbd.conf && grep -nE 'durable|share' /etc/ksmbd/ksmbd.conf
Gegenmaßnahmen: Was jetzt zu tun ist
Da ksmbd ein Kernel-Modul ist, ist der einzige saubere Fix ein Kernel-Update auf eine der oben gelisteten Fix-Versionen. Für Systeme, bei denen ein Reboot kurzfristig nicht möglich ist, lassen sich die Angriffsflächen jedoch zuverlässig reduzieren.
Kernel patchen
Auf den von Ihrer Distribution bereitgestellten Fix-Kernel (6.6-stable, 6.12.83, 6.18.24, 7.0.1, 7.1-rc1 oder neuer) aktualisieren und mit Wartungsfenster neu starten.
ksmbd deaktivieren
Wo SMB nicht zwingend kernelbasiert sein muss: ksmbd-Modul entladen, das System auf Samba (user-space) umstellen und 445/TCP vom Server-LAN trennen.
Netzwerk-Exposure reduzieren
Zugriff auf 445/TCP auf bekannte interne Subnetze begrenzen, externe Erreichbarkeit über Perimeter-Firewall ausschließen und Zugriffe über Jump-Hosts/Privileged Access auditieren.
Durable Handles prüfen
In ksmbd.conf prüfen, ob durable handles für die betroffenen Shares wirklich erforderlich sind. Sind sie deaktivierbar, schließt das den konkreten Trigger-Pfad.
Bevor Sie an einem zentralen Fileserver den Kernel tauschen: Snapshot der Storage-Volumes anlegen, Failover-Pfad dokumentieren und einen Recovery-Test des SMB-Mountings vorab einplanen. Kernel-Patches sind in den seltensten Fällen die Ursache für Folgeschäden — ungelöste Sessions und offene Locks beim Reboot dagegen sehr wohl.
Erkennung: Anomalien rund um ksmbd identifizieren
Ein Use-After-Free im Kernel hinterlässt selten saubere Spuren — weder im SMB-Audit noch in normalen Anwendungs-Logs. Hilfreich ist daher die Beobachtung von Kernel-Symptomen und Verbindungsmustern.
# Kernel-Trace nach ksmbd-Bezug filtern journalctl -k --since "7 days ago" | grep -iE 'ksmbd|use-after-free|KASAN|BUG:|general protection' # Auffällige Wiederholungen von Session-Disconnects journalctl -u ksmbd.service --since "24 hours ago" | grep -iE 'disconnect|durable|scavenger'
Auf Netzwerkseite ist relevant: Ein Angreifer, der den Bug gezielt triggert, erzeugt typischerweise kurzlebige SMB-Sessions mit Lock-Operationen und anschließendem abrupten Disconnect. Solche Muster lassen sich aus Flow-Daten oder SMB-Visibility-Tools ableiten.
Ein stabiler Server ohne sichtbare Kernel-Panics ist kein Beleg dafür, dass die Schwachstelle nicht ausgenutzt wurde. Use-After-Free-Primitive werden in geübten Angriffen oft so gewählt, dass sie keine Crash-Spuren erzeugen. Verlassen Sie sich nicht auf das Ausbleiben von Symptomen, sondern auf den Patch-Stand des Kernels.
Einordnung: Was Blackfort Kund:innen jetzt prüfen sollten
CVE-2026-31718 ist ein typischer Fall einer Kernel-Schwachstelle, die nicht auf eine breite Welle exponierter Internet-Systeme zielt, aber dort, wo sie sitzt, durchaus tief greift: in NAS-Appliances, High-Performance-Fileservern und Storage-Backends moderner Container-Plattformen. Genau dort, wo Wiederherstellungs- und Wartungsfenster planungsintensiv sind.
Für die Bewertung im eigenen Bestand sind drei Fragen entscheidend: Welche Hosts haben ksmbd aktiv geladen? Welche dieser Hosts bedienen Clients jenseits eines kontrollierten Management-Netzes? Und welche dieser Hosts laufen auf einer Kernel-Version, die im Fix-Korridor unten liegt?
- NVD-Eintrag „CVE-2026-31718“ (Source: kernel.org), Published 2026-05-01, Modified 2026-05-17
- ENISA EU Vulnerability Database, Eintrag EUVD-2026-26527
- kernel.org-Commits (verlinkt im NVD-Eintrag, fünf Patches über die Stable-Trees 6.6, 6.12, 6.18, 7.0 und 7.1-rc)