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

CVE-2026-31718 Overview

CVE-2026-31718 is a use-after-free vulnerability [CWE-416] in the Linux kernel's ksmbd in-kernel SMB3 server. The flaw resides in __ksmbd_close_fd() and is triggered through the durable file handle scavenger thread. When a durable handle survives a TCP disconnect without an SMB2_LOGOFF, session_fd_check() nulls fp->conn to preserve the handle, but leaves byte-range lock entries dangling on the freed connection's lock_list. The scavenger thread later dereferences this stale state, causing a slab use-after-free in kernel memory.

Critical Impact

Remote attackers reachable on an SMB port can trigger kernel memory corruption without authentication, leading to denial of service or potential remote code execution in kernel context.

Affected Products

• Linux Kernel (multiple stable branches with ksmbd enabled)
• Linux Kernel 7.1-rc1
• Systems exposing ksmbd SMB3 file shares with durable handle support

Discovery Timeline

• 2026-05-01 - CVE-2026-31718 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-31718

Vulnerability Analysis

The vulnerability is a use-after-free [CWE-416] in the ksmbd kernel module, which implements the SMB3 protocol server in-kernel. SMB3 supports durable file handles, allowing a client to reconnect after transient network loss without losing open file state. When a TCP session drops without a clean SMB2_LOGOFF, ksmbd attempts to keep the file pointer (fp) alive for later reconnection.

During this preservation step, session_fd_check() sets fp->conn = NULL and ksmbd_tcp_disconnect() frees the original ksmbd_conn object. However, byte-range lock entries on fp->lock_list remain linked into the freed connection's conn->lock_list through their smb_lock->clist field. The cleanup is asymmetric: the connection pointer is cleared, but the lock list membership is not.

The durable scavenger thread enforces a timeout for unreclaimed durable handles. When it fires, it calls __ksmbd_close_fd(NULL, fp), which iterates fp->lock_list and executes spin_lock(&fp->conn->llist_lock). Because fp->conn is NULL and the original connection has been freed, this both dereferences a null pointer and reaches into freed slab memory, producing the use-after-free condition.

Root Cause

The root cause is asymmetric cleanup of smb_lock->clist across the durable handle lifecycle. Three code paths must agree on lock-list ownership: the close path, session_fd_check(), and ksmbd_reopen_durable_fd(). The original code only nulled fp->conn without removing the lock entries from the connection's lock_list, leaving stale pointers into freed memory.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker reachable on TCP port 445 of a ksmbd-enabled host can open a file with a durable handle, acquire byte-range locks via SMB2 LOCK requests, then abruptly drop the TCP connection without sending SMB2_LOGOFF. After the durable scavenger timeout elapses, the kernel triggers the use-after-free during cleanup. Successful exploitation can corrupt kernel slab memory, leading to denial of service or escalation toward kernel code execution.

No public proof-of-concept exploit is currently listed for CVE-2026-31718, and the vulnerability is not present in the CISA Known Exploited Vulnerabilities catalog. The fix is described across upstream stable commits 235e3232, 3d668272, b34fc42c, and e33c65f0.

Detection Methods for CVE-2026-31718

Indicators of Compromise

• Kernel oops, KASAN reports, or general protection fault traces referencing __ksmbd_close_fd, ksmbd_durable_scavenger, or smb_lock.
• Unexpected ksmbd worker thread crashes correlated with abrupt SMB client TCP resets.
• Repeated SMB2 CREATE requests with DH2Q durable handle context followed by half-open TCP teardowns from the same source.

Detection Strategies

• Enable KASAN on test or canary kernels running ksmbd to catch use-after-free conditions in lock_list traversal before production impact.
• Hunt for SMB2 sessions that establish durable handles, hold byte-range locks, and terminate without SMB2_LOGOFF within the durable timeout window.
• Monitor dmesg and /var/log/kern.log for stack traces containing ksmbd_conn, llist_lock, or __ksmbd_close_fd.

Monitoring Recommendations

• Centralize kernel logs from all ksmbd hosts and alert on segfaults or panics in SMB code paths.
• Track per-source SMB connection churn; high rates of abrupt resets against shares with durable handles warrant investigation.
• Audit ksmbd process restarts and kernel module reloads as potential post-crash recovery indicators.

How to Mitigate CVE-2026-31718

Immediate Actions Required

• Apply the upstream stable kernel patches referenced by commits 235e3232, 3d668272, b34fc42c, and e33c65f0 from your distribution vendor.
• If patching is not yet possible, restrict TCP/445 exposure to trusted management networks using host or perimeter firewalls.
• Disable the ksmbd module on hosts that do not require an in-kernel SMB server and use samba user-space or no SMB service at all.

Patch Information

The fix corrects the asymmetric cleanup by safely skipping clist deletion when the list is empty and fp->conn is NULL, removing the lock from the old connection's lock_list in session_fd_check(), and re-adding the lock to the new connection's lock_list in ksmbd_reopen_durable_fd(). Patches are available at the Kernel Git Commit 235e323, Kernel Git Commit 3d66827, Kernel Git Commit b34fc42, and Kernel Git Commit e33c65f.

Workarounds

• Unload the ksmbd module with modprobe -r ksmbd on systems that do not actively serve SMB shares.
• Block inbound TCP/445 from untrusted networks at the host firewall until kernels are patched.
• Where SMB is required, migrate temporarily to user-space samba, which is not affected by this ksmbd-specific defect.

# Configuration example: blocklist ksmbd and restrict SMB exposure
echo 'blacklist ksmbd' | sudo tee /etc/modprobe.d/disable-ksmbd.conf
sudo modprobe -r ksmbd 2>/dev/null || true

# Restrict SMB to a trusted management subnet
sudo iptables -A INPUT -p tcp --dport 445 -s 10.0.0.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 445 -j DROP