Linux ksmbd CVE-2026-31718 and CVE-2026-31717 Patch Guide

Linux file servers that use the in-kernel SMB server should review two ksmbd CVEs now. CVE-2026-31718 is rated critical by the Linux kernel CNA with a CVSS 3.1 score of 9.8. CVE-2026-31717 is rated high at 8.8. Both issues affect ksmbd, the Linux kernel SMB3 server, not the normal Samba user-space daemon.

The highest-risk systems are Linux servers, NAS-style appliances, storage nodes, lab file servers, hosting support boxes, and custom kernels where ksmbd is enabled and reachable over SMB. If your server only uses Samba through smbd and does not load or run ksmbd, these specific CVEs are much less likely to apply. Still, confirm that rather than assuming.

What Changed

NVD and Ubuntu both list CVE-2026-31718 as a ksmbd use-after-free issue tied to durable SMB file-handle cleanup. The kernel CNA score is critical, with a network-reachable vector and no privileges required. In practical terms, a vulnerable ksmbd service exposed to a network should be treated as urgent.

CVE-2026-31717 is a related durable-handle ownership issue. It is not scored as unauthenticated, but it can matter on shared SMB services because an authenticated user may be able to interfere with another user’s orphaned durable handle if the server is vulnerable.

Who Is Affected

• Linux systems using the ksmbd in-kernel SMB server.
• Systems with SMB service reachable from untrusted networks, customer networks, VPN users, lab networks, or shared office networks.
• Custom kernels or vendor kernels in affected upstream version ranges before the stable fixes are backported.
• Ubuntu kernels where the Ubuntu CVE tracker marks the active kernel package as vulnerable.
• NAS, appliance, and embedded Linux products that use ksmbd under the hood.

NVD lists affected Linux kernel ranges for CVE-2026-31718 including 6.6.32 before 6.7, 6.9 before 6.12.84, 6.13 before 6.18.25, 6.19 before 7.0.2, and 7.1 rc1. CVE-2026-31717 has a similar NVD range covering 6.6.32 before 6.7, 6.9 before 6.18.25, 6.19 before 7.0.2, and 7.1 rc1. Distribution kernels may backport fixes, so use your OS vendor’s CVE tracker and package changelog as the final authority.

Safe Checks For Administrators

These checks do not validate the vulnerability against a live target. They only help confirm whether ksmbd is installed, loaded, enabled, or listening.

# Check whether the ksmbd kernel module is loaded.
lsmod | grep '^ksmbd' || true

# Check whether a ksmbd service exists and is enabled.
systemctl status ksmbd --no-pager
systemctl is-enabled ksmbd 2>/dev/null || true

# Check whether SMB ports are listening locally.
ss -ltnp | grep -E ':(139|445) '

# Check the running kernel.
uname -r

If you see smbd but not ksmbd, you are probably looking at Samba, not the in-kernel SMB server. That still deserves normal patching, but this post is about ksmbd-specific kernel CVEs.

What To Patch

Install the kernel update from your Linux vendor, then reboot into the fixed kernel unless your livepatch provider explicitly confirms coverage for these CVEs on the running kernel. Do not rely only on package installation; verify the active kernel after reboot.

# Debian and Ubuntu family.
apt update
apt full-upgrade
reboot
uname -r

# RHEL, AlmaLinux, Rocky Linux, CloudLinux, and Fedora family.
dnf update 'kernel*'
reboot
uname -r

For Ubuntu, check the Ubuntu CVE pages for CVE-2026-31718 and CVE-2026-31717 against the exact kernel flavor you run. Ubuntu’s page for CVE-2026-31718 shows a critical CVSS score while still assigning Ubuntu priority based on package exposure and kernel flavor status. That is why vendor status matters.

Temporary Risk Reduction

If ksmbd is not required, disable the service and unload the module during the maintenance window. If the server provides SMB shares through ksmbd, do not remove it blindly. Plan a service window, notify users, and decide whether to switch temporarily to a patched Samba service or restrict network access until the kernel is fixed.

# If ksmbd is not used, stop and disable it.
systemctl stop ksmbd
systemctl disable ksmbd

# If no ksmbd sessions are active, unload the module.
modprobe -r ksmbd

Use firewall controls to limit SMB exposure to trusted networks only. SMB should not be open to the public internet. For VPN and customer file-share environments, restrict access to known subnets while patching is scheduled.

Hosting, Proxmox, And Container Notes

Most Proxmox VE hosts do not need ksmbd on the hypervisor itself. If a Proxmox node is serving SMB directly from the host, verify whether that is intentional. Prefer storage designs that keep file-sharing roles separate from virtualization hosts where practical.

For Proxmox or clustered Linux systems, migrate or shut down guest workloads safely, update one node at a time, reboot into the fixed kernel, and confirm cluster health before moving to the next node. For container hosts, remember that containers share the host kernel. A vulnerable host kernel remains the trust boundary even if the SMB service is running outside a container.

What Logs To Review

• Kernel logs around SMB service crashes, general protection faults, kernel warnings, or ksmbd messages.
• Authentication logs for unexpected SMB users, new local accounts, or unusual login timing.
• File-share audit logs for unexpected access to sensitive shares.
• Firewall logs showing SMB access from untrusted source networks.
• Service manager logs showing ksmbd restarts or crashes.

journalctl -k --since "7 days ago" | grep -i ksmbd
journalctl -u ksmbd --since "7 days ago" --no-pager

Customer Communication

For managed servers, tell customers plainly that this is a Linux kernel SMB server issue. If ksmbd is enabled, the server needs either a fixed kernel or temporary SMB exposure reduction. If ksmbd is not enabled, document that finding and continue normal kernel patching.

For file-share users, explain any planned outage, expected reboot time, and whether SMB access will be restricted to trusted networks until updates are complete.

Fix I.T. Phill Guidance

Check ksmbd exposure first. If it is enabled and reachable, treat CVE-2026-31718 as urgent, apply the vendor kernel update, reboot, and confirm the active kernel. If ksmbd is unused, disable it and remove unnecessary SMB exposure. If the server uses Samba instead, do not confuse the two services; patch the kernel anyway, but track Samba advisories separately.

Sources

• NVD entry for CVE-2026-31718
• NVD entry for CVE-2026-31717
• Ubuntu CVE tracker for CVE-2026-31718
• Ubuntu CVE tracker for CVE-2026-31717
• Linux stable patch reference for CVE-2026-31718
• Linux stable patch reference for CVE-2026-31717

Need help checking ksmbd exposure, planning kernel reboots, or separating SMB service roles from virtualization hosts? Open a ticket through Help4Network.com.