CVE-2026-99280 · Runtime
NO FIX YET
A race in the Linux kernel's ksmbd SMB file server lets session cleanup remove procfs entries while a reader still uses them, which can corrupt memory. The sources do not state what an attacker can gain beyond a crash or instability.
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.
Systems running the Linux kernel ksmbd SMB server module, which is used to share files over SMB. Hosts that do not load ksmbd are not exposed. The sources do not name affected kernel version ranges.
Not affected if ksmbd-not-loaded, samba-only
Who cares ksmbd, linux, self-hosted, smb
lsmod | grep ksmbd.uname -r and compare it with the fixed kernel in the kernel.org stable branch the distribution ships.Unknown from the sources.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: drain session procfs readers before dropping table references
Session registration failure and connection cleanup can drop the table reference while the per-session procfs entry is still accessible. If a reader holds the last remaining reference, its final put calls proc_remove() from its own callback and waits for that callback to finish.
Remove the procfs entry before dropping the table reference in the registration failure path. Queue sessions removed during connection cleanup and drain their procfs readers after releasing both session locks, then return their table references. Keep the global hash node unhashed while a session is queued so a concurrent unregister cannot drop the reference again.
Previous-session replacement also destroys the file table before the session is finally freed. Detach the idr under the lock used by procfs file counters, and report zero files after it has been detached. This prevents a reader from accessing the idr during or after its destruction.
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.