CVE-2026-99278 · Runtime
NO FIX YET
The ksmbd SMB server in the Linux kernel does not cap how many authenticated sessions one connection can hold, because the pending limit only counts sessions still being set up. A remote client that authenticates repeatedly on one connection can exhaust server memory and resources.
first public Nov 7, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Only systems running the Linux kernel's ksmbd SMB file server (kernel SMB server module) are exposed, typically Linux hosts sharing files over SMB. Hosts that do not load ksmbd, or that use Samba instead, are not affected. The sources do not state which kernel versions are impacted.
Not affected if ksmbd-not-loaded, samba-only
Who cares file-server, ksmbd, linux-kernel, smb
uname -r and whether the ksmbd module is loaded with lsmod | grep ksmbdmax_sessions_per_connection setting in the ksmbd startup configurationUnknown from the sources.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: limit sessions on each connection
The pending setup limit only counts InProgress sessions. A client can complete authentication repeatedly and retain an unbounded number of Valid sessions on one connection.
Reserve a connection slot before allocating a session and retain a connection reference while authentication is in progress. The first SMB3 channel takes over that reservation; binding to another connection reserves one slot there. Reauthentication and authentication continuation reuse the existing reservation. Return slots on allocation or insertion failure, channel removal, and final session destruction.
Accept max_sessions_per_connection in reserved startup-request space and default to 64 when older tools leave it zero. Keep the request size and existing field offsets unchanged. Expose the configured limit in procfs. The existing connection limits bound the aggregate number of sessions without a separate global session allocation limit.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.