Race condition
Description
ksmbd: race condition in ksmbd_conn_wait_idle_sess_id() where rcount is shared across iterations causing an iteration-order dependent threshold. The code previously set rcount to 2 for the current connection and 1 for others, but because rcount was kept as a single variable outside the loop, subsequent iterations could compare sibling connections against an outdated threshold. This created a race where destroy_previous_session() could proceed while there are in-flight operations on sibling connections sharing the same SMB session, potentially tearing down a session prematurely. The patch recomputes rcount per connection inside the loop (rcount = (conn == curr_conn) ? 2 : 1) so each connection is validated against its own threshold regardless of iteration order, closing the race window.
Proof of Concept
Proposed PoC steps (high level):
- Preconditions: A Linux kernel with ksmbd enabled containing the vulnerable pre-patch logic and SMB3 multichannel support; two clients (A and B) connected to the same ksmbd-managed SMB session.
- Step 1: Client A starts a long-running I/O operation on the shared SMB session (e.g., large file write/read) to keep req_running > 0 for the current/other connections.
- Step 2: While A’s I/O is in flight, trigger a session teardown against the same SMB session (via destroy_previous_session() pathway, or an admin userland action that tears down the session for that sess_id).
- Step 3: Observe the race: before the patch, the per-iteration rcount could be stale for sibling connections, allowing the teardown to proceed or behave inconsistently while in-flight work exists on a sibling channel. You may observe teardown completing while a sibling still has req_running >= 1, or observe inconsistent teardown timing dependent on the hash iteration order.
- Step 4: On a patched kernel (post-fix), the per-connection rcount is recalculated inside the loop, ensuring each connection is checked against its own threshold. Re-run the steps and verify that teardown cannot complete until all connections report idle with respect to their own thresholds, regardless of iteration order.
- Prerequisites: kernel with vulnerable code present, multichannel SMB3 client support, instrumentation to observe req_running/teardown order (logs, tracepoints, or debugfs), and a reproducible method to invoke destroy_previous_session() mid-flight.
Note: A precise, deterministic PoC is difficult due to timing and environment variability, but the above steps illustrate the expected race behavior and how the fix eliminates it.
Commit Details
Author: DaeMyung Kang
Date: 2026-04-18 17:28 UTC
Message:
ksmbd: reset rcount per connection in ksmbd_conn_wait_idle_sess_id()
rcount is intended to be connection-specific: 2 for curr_conn, 1 for
every other connection sharing the same session. However, it is
initialised only once before the hash iteration and is never reset.
After the loop visits curr_conn, later sibling connections are also
checked against rcount == 2, so a sibling with req_running == 1 is
incorrectly treated as idle. This makes the outcome depend on the
hash iteration order: whether a given sibling is checked against the
loose (< 2) or the strict (< 1) threshold is decided by whether it
happens to be visited before or after curr_conn.
The function's contract is "wait until every connection sharing this
session is idle" so that destroy_previous_session() can safely tear
the session down. The latched rcount violates that contract and
reopens the teardown race window the wait logic was meant to close:
destroy_previous_session() may proceed before sibling channels have
actually quiesced, overlapping session teardown with in-flight work
on those connections.
Recompute rcount inside the loop so each connection is compared
against its own threshold regardless of iteration order.
This is a code-inspection fix for an iteration-order-dependent logic
error; a targeted reproducer would require SMB3 multichannel with
in-flight work on a sibling channel landing after curr_conn in hash
order, which is not something that can be triggered reliably.
Fixes: 76e98a158b20 ("ksmbd: fix race condition between destroy_previous_session() and smb2 operations()")
Cc: stable@vger.kernel.org
Signed-off-by: DaeMyung Kang <charsyam@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Triage Assessment
Vulnerability Type: Race condition
Confidence: HIGH
Reasoning:
The change fixes a logic race in session teardown for ksmbd connections. The original code could allow a teardown to proceed while there are in-flight operations on sibling connections due to an iteration-order dependent rcount. This creates a potential race condition with security implications (race window during shutdown of a session). The fix recomputes rcount per connection to ensure correct idle-wait behavior regardless of iteration order, closing the vulnerability window.
Verification Assessment
Vulnerability Type: Race condition
Confidence: HIGH
Affected Versions: < 7.0-rc6
Code Diff
diff --git a/fs/smb/server/connection.c b/fs/smb/server/connection.c
index a26899d12df17b..b5e077f272cffc 100644
--- a/fs/smb/server/connection.c
+++ b/fs/smb/server/connection.c
@@ -237,7 +237,7 @@ int ksmbd_conn_wait_idle_sess_id(struct ksmbd_conn *curr_conn, u64 sess_id)
{
struct ksmbd_conn *conn;
int rc, retry_count = 0, max_timeout = 120;
- int rcount = 1, bkt;
+ int rcount, bkt;
retry_idle:
if (retry_count >= max_timeout)
@@ -246,8 +246,7 @@ int ksmbd_conn_wait_idle_sess_id(struct ksmbd_conn *curr_conn, u64 sess_id)
down_read(&conn_list_lock);
hash_for_each(conn_list, bkt, conn, hlist) {
if (conn->binding || xa_load(&conn->sessions, sess_id)) {
- if (conn == curr_conn)
- rcount = 2;
+ rcount = (conn == curr_conn) ? 2 : 1;
if (atomic_read(&conn->req_running) >= rcount) {
rc = wait_event_timeout(conn->req_running_q,
atomic_read(&conn->req_running) < rcount,