CVE-2026-31718

What it actually does

This is a Linux kernel ksmbd use-after-free flaw in durable SMB file-handle cleanup. A durable SMB handle can survive a TCP disconnect, causing ksmbd to preserve the file pointer while nulling its connection pointer. If byte-range lock state remains linked to the old connection and the durable scavenger later expires the handle, cleanup can dereference stale or invalid connection-related list state. Because this occurs in kernel context and is reachable over the network through the SMB server, successful exploitation can cause kernel memory corruption, denial of service through a kernel crash, and potentially arbitrary code execution with kernel privileges.

Why it matters to the business

Systems using the in-kernel Linux SMB server may be vulnerable to a remote, high-severity attack that can crash file-sharing services or potentially compromise the host. Impact is highest for internet-exposed or broadly reachable SMB services, especially where guest or unauthenticated access is allowed. Although this issue is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low stable EPSS score, the CVSS 9.8 rating and kernel-level attack surface make timely remediation important for any Linux system providing SMB file shares through ksmbd.

How an attack unfolds

An attacker first identifies a Linux host exposing SMB through ksmbd, typically on TCP port 445. They establish an SMB session and exercise durable file-handle behavior by opening a file with durable-handle semantics and creating byte-range lock state. Instead of performing a normal SMB logoff, the attacker abruptly closes the TCP connection so the durable handle is preserved for possible reconnection. This leaves lock-related state associated with the old connection while the file pointer no longer has a valid connection reference. When the durable-handle scavenger later times out the preserved handle, ksmbd attempts to clean up the stale lock state and can access freed kernel memory. Depending on heap layout, timing, and exploit reliability, the outcome may be a kernel oops/panic or more serious memory corruption that could be shaped toward code execution in kernel context.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the ksmbd fix for durable handle lock-list lifetime management. Because no exact fixed versions were supplied, use vendor advisories and package changelogs to confirm the patch is included. If ksmbd is not required, disable it entirely, unload the ksmbd module where feasible, and prevent it from starting at boot. As compensating controls, restrict TCP/445 exposure to trusted networks, block internet access to SMB, disable guest or anonymous SMB access, limit write access to shares, and monitor for abnormal SMB disconnect patterns. If SMB service is required but ksmbd cannot be patched promptly, consider migrating affected file-sharing workloads to a patched kernel or an alternative supported SMB implementation until the kernel is remediated.

How to confirm the fix worked

Confirm whether the system uses ksmbd rather than only user-space Samba by checking loaded modules, kernel configuration, running services, and listeners on TCP/445. Validate remediation by confirming the installed kernel package version matches a vendor advisory containing the ksmbd durable scavenger/use-after-free fix, or by reviewing kernel changelogs for changes to session_fd_check(), __ksmbd_close_fd(), and ksmbd_reopen_durable_fd(). Reboot into the patched kernel and verify the old vulnerable kernel is not still running. Confirm ksmbd is disabled if mitigation is chosen instead of patching. Exposure validation should include network checks for reachable SMB services and host checks for ksmbd module presence. In test environments, use non-production validation to ensure abrupt SMB disconnects with durable handles and byte-range locks no longer produce kernel oops, KASAN reports, or ksmbd crashes.

Typical attack path

1. Scan for hosts exposing SMB services, especially TCP/445, and identify Linux ksmbd-backed shares where possible.
2. Establish an SMB session and open a file using durable-handle behavior.
3. Create byte-range lock state associated with the durable file handle.
4. Terminate the TCP connection abruptly without a clean SMB2_LOGOFF.
5. Wait for the ksmbd durable scavenger to expire and close the preserved handle.
6. Trigger the vulnerable cleanup path in __ksmbd_close_fd(), causing stale connection or lock-list state to be accessed.
7. Use the resulting kernel memory corruption to crash the host or attempt further exploitation.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and EDR telemetry for ksmbd-related faults around SMB connection activity. Key sources include /var/log/kern.log, /var/log/messages, journalctl -k, dmesg history, kdump/vmcore artifacts, kernel oops reports, KASAN/KFENCE reports, and service monitoring for unexpected reboots or panics. Look for stack traces involving __ksmbd_close_fd(), durable-handle cleanup, session_fd_check(), ksmbd_tcp_disconnect(), or ksmbd_reopen_durable_fd(). Correlate these events with SMB logs or network telemetry showing repeated TCP/445 connections that terminate abruptly without normal SMB logoff, especially where durable file handles and byte-range locking are used. Because no public exploit indicators or malware artifacts are provided, absence of these strings does not prove the host was not targeted; prioritize correlation of kernel memory errors with suspicious SMB connection patterns.

• BUG: KASAN: slab-use-after-free
• slab-use-after-free
• use-after-free in __ksmbd_close_fd
• __ksmbd_close_fd
• session_fd_check
• ksmbd_reopen_durable_fd
• ksmbd_tcp_disconnect
• ksmbd:
• ksmbd
• TCP/445
• SMB2_LOGOFF
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• kdump
• vmcore

What your security team should do

• Prioritize patching Linux hosts that expose ksmbd SMB services, especially systems reachable from untrusted networks or allowing guest access.
• Inventory all systems listening on TCP/445 and determine whether they use the in-kernel ksmbd server.
• Disable or unload ksmbd wherever it is not explicitly required.
• Restrict SMB access with host firewalls, network ACLs, VPN requirements, and segmentation; do not expose SMB directly to the internet.
• Disable guest or anonymous SMB access and enforce least-privilege share permissions.
• Review kernel logs for evidence of ksmbd crashes, kernel oops messages, KASAN use-after-free reports, or repeated abrupt SMB disconnects.
• Add SIEM detections for ksmbd-related kernel faults and SMB sessions ending without clean logoff patterns if SMB telemetry is available.
• Track vendor kernel advisories because fixed package versions vary by distribution and were not provided in the input.
• After patching, reboot systems and verify they are running the corrected kernel, not merely that the package is installed.