CVE-2026-31711: smb: server: fix active_num_conn leak on transport allocation failure
In the Linux kernel, the following vulnerability has been resolved:
smb: server: fix active_num_conn leak on transport allocation failure
Commit 77ffbcac4e56 ("smb: server: fix leak of active_num_conn in
ksmbd_tcp_new_connection()") addressed the kthread_run() failure
path. The earlier alloc_transport() == NULL path in the same
function has the same leak, is reachable pre-authentication via any
TCP connect to port 445, and was empirically reproduced on UML
(ARCH=um, v7.0-rc7): a small number of forced allocation failures
were sufficient to put ksmbd into a state where every subsequent
connection attempt was rejected for the remainder of the boot.
ksmbd_kthread_fn() increments active_num_conn before calling
ksmbd_tcp_new_connection() and discards the return value, so when
alloc_transport() returns NULL the socket is released and -ENOMEM
returned without decrementing the counter. Each such failure
permanently consumes one slot from the max_connections pool; once
cumulative failures reach the cap, atomic_inc_return() hits the
threshold on every subsequent accept and every new connection is
rejected. The counter is only reset by module reload.
An unauthenticated remote attacker can drive the server toward the
memory pressure that makes alloc_transport() fail by holding open
connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN
(0x00FFFFFF); natural transient allocation failures on a loaded
host produce the same drift more slowly.
Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the
alloc_transport() failure path, decrement active_num_conn gated on
server_conf.max_connections.
Repro details: with the patch reverted, forced alloc_transport()
NULL returns leaked counter slots and subsequent connection
attempts -- including legitimate connects issued after the
forced-fail window had closed -- were all rejected with "Limit the
maximum number of connections". With this patch applied, the same
connect sequence produces no rejections and the counter cycles
cleanly between zero and one on every accept.
Security readout for executives and security teams
Plain-English summary
A flaw in Linux’s ksmbd SMB server can permanently exhaust its connection allowance when memory allocation fails. An unauthenticated remote party reaching TCP port 445 can increase memory pressure and accelerate the failure. Once exhausted, the server rejects legitimate SMB connections until its module is reloaded, creating a denial of service without exposing or altering data.
Executive priority
Prioritize affected, reachable ksmbd servers because exploitation needs no account or user action and can disrupt file-sharing availability. Accelerate remediation for internet-facing systems and operationally critical SMB services. Systems without ksmbd can be deprioritized after validation. No confidentiality or integrity impact is identified in the supplied record.
Technical view
ksmbd increments active_num_conn before allocating a connection transport. If alloc_transport() returns NULL, the socket is released but the counter is not decremented. Each failure therefore permanently consumes a max_connections slot. Reaching the configured limit causes all later connections to be rejected. The kernel fix decrements the counter on this failure path, matching the existing rollback pattern.
Likely exposure
Exposure requires Linux systems running ksmbd with TCP port 445 reachable. Internet-facing or broadly accessible SMB services face greater risk, while systems not using ksmbd are unaffected by this path. The supplied version data is irregular and distribution kernels may contain backports, so assess the exact kernel build against vendor guidance and referenced fixes.
Exploitation context
The source describes successful reproduction under forced allocation failures and explains how remote unauthenticated connections can induce memory pressure. However, it provides no evidence of real-world active exploitation, and the record is not marked as CISA KEV. Natural allocation failures can also accumulate the leaked counter without malicious activity.
Researcher notes
The key invariant is that active_num_conn must be rolled back whenever transport setup fails after the earlier increment. The failure is persistent for the module’s lifetime and affects availability only. The bundle lists several stable-branch fixes, but its affected-version entries include commit hashes and an anomalous version value; confirm branch ancestry or vendor backport status rather than relying solely on version strings.
Mitigation direction
Apply a vendor kernel update containing the referenced stable fix for the deployed branch.
Until updated, restrict TCP port 445 access to trusted systems and networks.
Disable ksmbd where SMB server functionality is unnecessary.
Treat module reload only as temporary recovery; it resets the counter but does not remove exposure.
Monitor ksmbd connection-limit rejections and host memory pressure.
Validation and detection
Confirm whether ksmbd is enabled and listening on TCP port 445.
Identify the exact kernel build and check for the applicable referenced stable fix.
Review distribution security guidance because version numbers alone may not reflect backported patches.
Check logs for repeated maximum-connection-limit rejections affecting legitimate clients.
After updating, verify connection handling no longer permanently consumes max_connections slots after allocation failures.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-31711 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
8Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.