CVE-2026-31718: Linux Kernel ksmbd Use-After-Free Vulnerability

Overview: What makes CVE-2026-31718 dangerous

CVE-2026-31718 affects ksmbd, the SMB server implementation built into the Linux kernel. According to the NVD entry, the issue is a use-after-free in the __ksmbd_close_fd() function, triggered by asymmetric cleanup when closing file handles. The ENISA record EUVD-2026-26527 references the same defect and assigns it the weakness class CWE-416 (Use After Free).

The trigger condition involves so-called durable file handles: when an SMB session breaks, the file handle persists for a short window so the client can transparently reconnect. Inside that window, the kernel data path is left in an inconsistent state — a primitive that an attacker with network access to the SMB service can exploit.

From a defender's perspective, the CVSS vector profile is what matters most: network-based exploitation, no authentication, no user interaction. That combination typically pushes the issue straight into the „patch immediately“ bucket. Whether the bug becomes remote code execution in practice depends on the additional primitives an attacker can build on top of the corrupted kernel heap — but kernel-level memory corruption is generally treated as a high-value foothold.

Technical analysis: Asymmetric cleanup between two paths

The root cause is that two independent cleanup paths share the same state but only reset part of it consistently. The briefing summarises this as „asymmetric cleanup logic“ — the same description is reflected in the NVD technical details.

On a regular disconnect, ksmbd invokes session_fd_check(). That routine sets fp->conn = NULL, releases the connection structure, and unbinds the file pointer from the connection. What it does not do: detach the byte-range locks hanging in fp->lock_list from the original conn->lock_list. Their smb_lock->clist entries continue to point into already-freed memory.

The NVD entry lists five kernel.org commits that fix the defect across the maintained branches. The patches realign the cleanup paths so that either the locks are removed before the connection structure is freed, or the scavenger thread correctly handles the nulled-out pointer.

Affected kernel versions and patch status

The NVD entry documents several parallel version trees that received the fix. In practice that means: anyone running ksmbd should match the precise distribution kernel against the fix line, rather than just looking at the major version.

A quick version check on a running system:

# Inspect kernel version and ksmbd module
uname -r
modinfo ksmbd 2>/dev/null | grep -E '^(filename|version|srcversion)'

# Is the server running and listening on 445/TCP?
ss -ltnp '( sport = :445 )'
systemctl is-active ksmbd 2>/dev/null

# Review configured shares and durable-handle options
test -f /etc/ksmbd/ksmbd.conf && grep -nE 'durable|share' /etc/ksmbd/ksmbd.conf

Mitigations: What to do now

Because ksmbd is a kernel module, the only clean fix is a kernel upgrade to one of the fixed versions listed above. For systems where an immediate reboot is hard, the attack surface can still be reduced reliably.

Detection: Spotting ksmbd anomalies

A kernel use-after-free rarely leaves clean traces — neither in the SMB audit log nor in regular application logs. Useful signals are therefore kernel symptoms and connection patterns.

# Filter the kernel trace for ksmbd references
journalctl -k --since "7 days ago" | grep -iE 'ksmbd|use-after-free|KASAN|BUG:|general protection'

# Look for repeated session-disconnect events
journalctl -u ksmbd.service --since "24 hours ago" | grep -iE 'disconnect|durable|scavenger'

On the network side, an attacker who deliberately triggers the bug will typically generate short-lived SMB sessions involving lock operations followed by abrupt disconnects. Such patterns are derivable from flow data or SMB-visibility tooling.

Outlook: What Blackfort customers should check now

CVE-2026-31718 is a textbook example of a kernel-level defect that does not target a broad sweep of internet-exposed systems but does cut deep where it lands: NAS appliances, high-performance file servers, and storage backends behind modern container platforms. Exactly the systems where recovery and maintenance windows take planning.

For your own estate, three questions are decisive: Which hosts actively load ksmbd? Which of those serve clients beyond a controlled management network? And which of them are running a kernel version that sits on the affected side of the fix range?