CVE-2026-31711
Memory Leak in ksmbd SMB Server
Publication date: 2026-05-01
Last updated on: 2026-05-06
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 6.2 |
| linux | linux_kernel | 6.2 |
| linux | linux_kernel | 6.2 |
| linux | linux_kernel | 6.2 |
| linux | linux_kernel | From 6.7 (inc) to 6.12.84 (exc) |
| linux | linux_kernel | From 6.13 (inc) to 6.18.25 (exc) |
| linux | linux_kernel | From 6.19 (inc) to 7.0.2 (exc) |
| linux | linux_kernel | From 5.15.91 (inc) to 5.16 (exc) |
| linux | linux_kernel | From 6.1.9 (inc) to 6.2 (exc) |
| linux | linux_kernel | From 6.2.1 (inc) to 6.6.136 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-401 | The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the Linux kernel's SMB server implementation. It involves a resource leak where the active connection counter (active_num_conn) is not properly decremented when a transport allocation failure occurs during a new TCP connection to port 445.
Specifically, when the function alloc_transport() fails and returns NULL, the code releases the socket and returns an error without decrementing the active connection counter. This causes the counter to permanently consume connection slots.
An unauthenticated remote attacker can exploit this by opening connections with large payloads, causing allocation failures and leaking connection slots. Eventually, this leads to the server rejecting all new connection attempts until the module is reloaded.
How can this vulnerability impact me? :
The impact of this vulnerability is a denial of service (DoS) condition on the SMB server.
Because the active connection counter leaks slots on allocation failure, the server can reach its maximum connection limit prematurely. Once this limit is hit, all subsequent connection attempts are rejected, effectively preventing legitimate users from connecting.
This state persists until the kernel module is reloaded, which may require administrative intervention and cause service disruption.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves a leak of the active_num_conn counter in the ksmbd server component of the Linux kernel when alloc_transport() fails. Detection would involve monitoring the ksmbd server behavior, specifically looking for repeated connection rejections with messages like "Limit the maximum number of connections" even when the system is not under heavy load.
Since the issue is triggered by connection attempts to TCP port 445, you can monitor network traffic for unusual patterns of connections to this port.
Suggested commands to help detect the issue include:
- Use netstat or ss to monitor connections on port 445: `ss -tn sport = :445` or `netstat -an | grep ':445'`
- Check kernel logs for repeated connection rejection messages related to max_connections limits: `dmesg | grep 'Limit the maximum number of connections'`
- Monitor the number of active connections and the ksmbd module status to detect if the active_num_conn counter is stuck or leaking.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is fixed by a patch that ensures the active_num_conn counter is properly decremented on alloc_transport() failure, preventing the connection slot leak.
Immediate mitigation steps include:
- Apply the patch or update the Linux kernel to a version that includes the fix for this vulnerability.
- If patching is not immediately possible, consider periodically reloading the ksmbd kernel module to reset the active_num_conn counter, as the counter is only reset by module reload.
- Limit or monitor incoming TCP connections to port 445 to reduce the risk of an attacker driving the server into the failure state.