CVE-2026-31711

What it actually does

This vulnerability is a remotely reachable denial-of-service flaw in the Linux kernel ksmbd SMB server. When a new TCP connection reaches ksmbd and transport allocation fails, the kernel can fail to decrement the active connection counter. Each failed allocation permanently consumes one slot from the configured maximum connection pool until the ksmbd module is reloaded or the system is rebooted. Once enough leaked slots accumulate, ksmbd rejects all subsequent SMB connection attempts, including legitimate ones. The issue is reachable before authentication over TCP port 445 and does not require user interaction or credentials. It affects availability only; it does not directly provide code execution, data disclosure, or privilege escalation.

Why it matters to the business

Systems using the in-kernel Linux SMB server can become unable to accept new file-sharing connections, disrupting access to shared files, application dependencies, backups, or administrative workflows that rely on SMB. Because exploitation is unauthenticated and network-accessible, internet-exposed or broadly reachable SMB services are at higher operational risk. The EPSS score is currently low and there is no known CISA KEV listing or ransomware association, but the flaw is simple to trigger in principle and can also be amplified by normal memory pressure on busy hosts. Organizations with Linux-based NAS, file servers, appliances, or embedded systems using ksmbd should prioritize patching based on exposure of TCP/445 and business reliance on SMB availability.

How an attack unfolds

An attacker identifies a Linux host running ksmbd with TCP port 445 reachable. They repeatedly open SMB/TCP connections and attempt to create memory pressure around connection handling, for example by holding connections open and sending large RFC1002 length values within the protocol limit. Under allocation failure conditions, ksmbd releases the socket but fails to roll back the active connection counter. Each failure silently reduces the remaining usable connection capacity. After enough leaked counter slots accumulate to reach the configured maximum connection limit, ksmbd begins rejecting every new connection. Legitimate users and applications can no longer establish SMB sessions until the module is reloaded, the system is rebooted, or a corrected kernel is installed.

How to fix it

Apply a Linux kernel update that includes the ksmbd fix for the active_num_conn rollback on the alloc_transport() failure path. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution, appliance vendor, or kernel stable branch once available. Where immediate patching is not possible, reduce exposure by disabling ksmbd if it is not required, blocking or tightly restricting inbound TCP/445 to trusted networks, placing SMB behind VPN or private network controls, and lowering the likelihood of memory pressure on SMB servers. If the service has already entered the failed state, reloading the ksmbd module or rebooting can restore service temporarily, but this is not a durable fix without the patched kernel.

How to confirm the fix worked

Confirm whether the host is using ksmbd and whether TCP/445 is reachable from untrusted networks. Validate remediation by checking that the running kernel package or source tree includes the fix that decrements active_num_conn when alloc_transport() returns NULL in the ksmbd connection path. After patching, perform controlled SMB connection tests and verify that transient allocation failures or connection churn do not cause persistent rejection of all new connections. Operationally, monitor that legitimate SMB clients can establish new sessions and that kernel logs no longer show repeated maximum-connection-limit rejections under normal load.

Typical attack path

1. Scan for hosts exposing SMB over TCP port 445.
2. Determine or assume the target is using Linux ksmbd rather than a user-space SMB server.
3. Open repeated unauthenticated TCP connections to the SMB service.
4. Hold connections open and/or send large RFC1002 session lengths to increase memory pressure during transport allocation.
5. Trigger transport allocation failures in ksmbd before authentication completes.
6. Cause active connection counter slots to leak one by one.
7. Drive the leaked counter to the configured maximum connection threshold.
8. Observe that new SMB connection attempts are rejected, producing a denial of service for legitimate users.

How to detect it

To determine whether exploitation or accidental triggering already occurred, review kernel logs, system journals, firewall logs, NetFlow, and SMB service telemetry for signs of connection exhaustion. Key evidence includes repeated ksmbd messages indicating that the maximum number of connections was reached, sudden rejection of all new SMB sessions, and bursts of unauthenticated TCP/445 connections before the outage. Look for many short-lived or half-open connections to TCP/445 from one or more sources, connections held open without completing normal SMB negotiation, and unusually large RFC1002 session length values. Correlate these events with memory pressure, allocation failure messages, and user reports of SMB shares becoming unavailable. Because the flaw causes a counter leak rather than writing a unique payload or file, forensic evidence is likely to be behavioral rather than artifact-based. If named threat actors are not reported and there is no KEV listing, prioritize broad network and service-log hunting over attribution-specific searches.

• Limit the maximum number of connections
• ksmbd
• TCP/445
• port 445
• RFC1002
• 0x00FFFFFF
• MAX_STREAM_PROT_LEN
• alloc_transport
• active_num_conn
• ENOMEM

What your security team should do

• Inventory Linux systems, NAS devices, appliances, and embedded platforms that expose SMB over TCP/445 and determine whether they use ksmbd.
• Prioritize remediation for ksmbd systems reachable from the internet, partner networks, user VLANs, or other broad network segments.
• Apply vendor kernel updates as soon as fixed packages are available; where versions are not yet published, track the relevant distribution and upstream stable kernel advisories.
• Temporarily restrict TCP/445 to required clients only, preferably through host firewalls, network ACLs, or VPN-only access.
• Disable ksmbd on systems that do not require SMB file sharing or replace exposure with a better-controlled SMB service until patching is complete.
• Monitor kernel and system logs for repeated SMB connection limit messages, connection allocation failures, and sudden drops in successful SMB logons.
• Prepare an operational recovery procedure to reload the ksmbd module or reboot affected hosts if they stop accepting SMB connections before patching.
• Treat sustained unauthenticated SMB connection bursts as suspicious, even though this vulnerability is not currently listed in KEV and has low observed EPSS activity.