CVE-2026-31477

What it actually does

This flaw affects the Linux kernel ksmbd in-kernel SMB server, specifically error handling in smb2_lock(). A remote client can trigger paths where a detached SMB lock object and its associated file-lock structure are not freed, causing kernel memory leaks, and under allocation-failure conditions the rollback path can dereference a NULL pointer. The practical technical result is denial of service: memory/resource exhaustion over time or an immediate kernel oops/panic depending on kernel configuration and failure path. Confidentiality and integrity are not directly impacted based on the available description.

Why it matters to the business

Systems using the Linux kernel ksmbd SMB server may become unstable, stop serving file shares, or crash, disrupting file access for users and applications that depend on SMB. Because the vulnerability is network reachable, requires no authentication according to the CVSS vector, and has high availability impact, exposed SMB services should be treated as operationally important even though EPSS is currently low, there is no known KEV listing, and no public exploit maturity is reported.

How an attack unfolds

An attacker first identifies a host exposing ksmbd-backed SMB service, typically on TCP port 445. The attacker establishes an SMB session and sends SMB2 LOCK or unlock-related requests crafted to drive smb2_lock() into vulnerable error-handling paths after an internal lock object has been removed from its tracking list. In some cases, repeated requests can leak kernel memory by preventing detached lock objects from being freed. In another path, if allocation fails during rollback, the kernel can dereference a NULL file-lock pointer, causing a kernel oops or panic. The attacker’s objective is service disruption rather than data theft: the SMB service, affected workload, or entire host may become unavailable.

How to fix it

Upgrade to a Linux kernel build that includes the ksmbd smb2_lock() fix from the relevant distribution or kernel maintainer. Because no specific fixed versions were provided, use vendor advisories for the deployed distribution and kernel branch to identify the first corrected package. If immediate patching is not possible, reduce exposure by disabling ksmbd if it is not required, blocking inbound SMB access from untrusted networks, restricting TCP/445 to trusted clients through firewalls or security groups, and preferring a patched SMB implementation. Reboot into the updated kernel after patch installation, since kernel fixes are not active until the patched kernel is running unless a validated livepatch is available.

How to confirm the fix worked

Confirm whether ksmbd is enabled and reachable, then verify the running kernel package includes the vendor fix. On Linux hosts, check the active kernel with uname -r and compare it against the distribution’s security advisory or changelog for this vulnerability. Verify that ksmbd is not loaded or listening if the mitigation is to disable it. Network validation should confirm TCP/445 is not reachable from untrusted segments. After patching, perform controlled SMB lock/unlock functional tests and monitor kernel logs for absence of ksmbd-related oops, NULL pointer dereference, or memory-allocation failure messages.

Typical attack path

1. Scan for systems exposing SMB over TCP/445 or otherwise reachable SMB services.
2. Determine or assume the target is using Linux ksmbd rather than only user-space Samba.
3. Establish an SMB2-capable connection to the service.
4. Send SMB2 LOCK or unlock sequences that exercise vulnerable smb2_lock() error-handling paths.
5. Repeat requests to amplify kernel memory leakage or induce allocation pressure.
6. Trigger service instability, kernel oops, panic, or host-level denial of service.

How to detect it

To assess prior exploitation, review host and kernel logs from SMB-serving Linux systems for ksmbd-related crashes, memory leaks, NULL pointer dereferences, kernel oops/panic events, and unexpected reboots. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, systemd service restart history, and network telemetry for TCP/445. Look for repeated SMB2 LOCK activity, repeated short SMB sessions, or spikes in inbound SMB traffic preceding kernel instability. Because this is a denial-of-service vulnerability rather than a code-execution issue, durable host artifacts may be limited to crash logs, memory-pressure events, and network records. If named threat actor activity is not present in available intelligence, focus detection on behavior: unauthenticated or anomalous SMB2 lock/unlock sequences followed by ksmbd errors, kernel warnings, memory allocation failures, or reboot events.

• ksmbd
• smb2_lock
• NULL pointer dereference
• kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• vfs_lock_file
• smb2_lock()
• ksmbd:
• SMB2 LOCK
• TCP/445
• Out of memory
• page allocation failure
• general protection fault
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash
• vmcore

What your security team should do

• Prioritize patching systems that expose ksmbd-backed SMB services to untrusted networks or support business-critical file sharing.
• Inventory Linux hosts listening on TCP/445 and distinguish ksmbd deployments from user-space Samba deployments.
• If patching is delayed, disable ksmbd where possible or restrict SMB access to explicitly trusted networks and clients.
• Review kernel and system logs for ksmbd crashes, NULL pointer dereferences, SMB2 lock errors, or unexplained reboots since the vulnerability publication date.
• Add monitoring for unusual volumes of SMB2 LOCK traffic or repeated SMB connection attempts from the same source.
• Ensure incident response playbooks treat kernel oops or host reboot events on SMB servers as potential exploitation until ruled out.
• Track distribution-specific advisories because fixed kernel versions vary by vendor, kernel branch, and backport policy.