CVE-2026-90162: ksmbd: defer publishing granted locks to prevent UAF/double-free race
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: defer publishing granted locks to prevent UAF/double-free race
In smb2lock(), mid-batch granted locks are published to connection-wide (conn->locklist) and file-wide (fp->locklist) lists immediately upon vfslockfile() success, while also remaining tracked on the stack-local rollbacklist.
If a subsequent element in the same SMB2LOCK request array fails validation or execution, the thread jumps to out: and walks rollbacklist to undo previously granted locks. However, because the granted lock was already published to conn->locklist, a concurrent UNLOCK request on the same connection can find the lock object and kfree() it before the rollback loop executes.
When the granting thread subsequently walks rollbacklist, it dereferences and frees the already-freed ksmbdlock structure, resulting in a Use-After-Free and Double-Free (on both ksmbdlock and struct filelock).
Fix this by deferring the publication of granted locks to conn->locklist and fp->locklist until after the entire array of lock elements has been processed without error. Mid-batch grants remain tracked exclusively on the request-local rollbacklist until the whole batch succeeds, eliminating the race window.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this race condition?
Systems using the Linux kernel ksmbd SMB server component are exposed when they process SMB2 lock requests. The race involves concurrent lock and UNLOCK activity on the same connection.
What does an attacker need to trigger the issue?
The attacker needs to send an SMB2_LOCK request containing multiple lock elements such that a lock is granted before a later element fails validation or execution, while a concurrent UNLOCK request operates on the same connection.
What happens if the race is triggered?
A concurrent UNLOCK can free a granted lock before the original request's rollback handling runs. The rollback path can then dereference and free the same ksmbd_lock and struct file_lock again, causing use-after-free and double-free conditions.
Is there a configuration workaround described if patching is not immediately possible?
No configuration workaround is provided in the available data. The described fix changes ksmbd so granted locks are not published to connection-wide and file-wide lock lists until the full SMB2 lock-element array completes without error.