mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sung Byeongchan <tjdqudcks0424@naver.com>
To: Namjae Jeon <linkinjeon@kernel.org>,
	ChenXiaoSong <chenxiaosong@chenxiaosong.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Tom Talpey <tom@talpey.com>,
	linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] ksmbd: validate share path for batch oplock reconnects
Date: Wed,  7 Oct 2026 16:44:44 +0900	[thread overview]
Message-ID: <20261007074444.84875-1-tjdqudcks0424@naver.com> (raw)

Durable reconnects backed by a lease reach
ksmbd_validate_name_reconnect(), which rejects reconnecting an open through
a different share root.  Batch oplock reconnects return immediately after
checking the oplock level and therefore skip that validation.

An authenticated client which owns a disconnected durable batch-oplock
handle can present its valid reconnect context on another tree.  The
preserved open is then rebound to that tree even when the client can no
longer connect to the source share.

Route successful batch-oplock reconnects through the same name and
share-root validation as lease reconnects.  Keep invalid oplock levels on
the existing error path.

This was found by source review with AI assistance.  In two independent
boots, a same-owner client was denied a new tree connect to the source
share, but reconnected its durable handle on an unrelated read-only share
and read the source file.  Routing the batch-oplock path through the
validator rejected the cross-share reconnect and preserved same-share
reconnects.

Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>
---
 fs/smb/server/oplock.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/smb/server/oplock.c b/fs/smb/server/oplock.c
index 25ff8408f0ba2..70b7b085d4fdc 100644
--- a/fs/smb/server/oplock.c
+++ b/fs/smb/server/oplock.c
@@ -2489,9 +2489,10 @@ int smb2_check_durable_oplock(struct ksmbd_conn *conn,
 		if (opinfo->level != SMB2_OPLOCK_LEVEL_BATCH) {
 			pr_err("oplock level is not equal to SMB2_OPLOCK_LEVEL_BATCH\n");
 			ret = -EBADF;
+			goto out;
 		}
 
-		goto out;
+		goto validate_name;
 	}
 
 	if (memcmp(conn->ClientGUID, fp->client_guid,
@@ -2528,6 +2529,7 @@ int smb2_check_durable_oplock(struct ksmbd_conn *conn,
 		goto out;
 	}
 
+validate_name:
 	if (!ksmbd_inode_pending_delete(fp))
 		ret = ksmbd_validate_name_reconnect(share, fp, name);
 out:
-- 
2.43.0


             reply	other threads:[~2026-10-07  7:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07  7:44 Sung Byeongchan [this message]
2026-10-07 14:51 ` Namjae Jeon
2026-10-08  3:58   ` ChenXiaoSong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261007074444.84875-1-tjdqudcks0424@naver.com \
    --to=tjdqudcks0424@naver.com \
    --cc=chenxiaosong@chenxiaosong.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®