From: munan Huang <munanevil@gmail.com>
To: linkinjeon@kernel.org, smfrench@gmail.com,
senozhatsky@chromium.org, tom@talpey.com
Cc: linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org,
munan Huang <munanevil@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH] ksmbd: fix use-after-free in __ksmbd_close_fd() lock cleanup
Date: Thu, 2 Apr 2026 08:39:12 +0000 [thread overview]
Message-ID: <20260402083912.457676-1-munanevil@gmail.com> (raw)
In __ksmbd_close_fd(), when cleaning up byte-range locks on a durable
file handle closed by the scavenger, the lock cleanup loop
unconditionally dereferences fp->conn->llist_lock to remove each lock
from the connection's list:
list_for_each_entry_safe(smb_lock, tmp_lock, &fp->lock_list, flist) {
spin_lock(&fp->conn->llist_lock);
list_del(&smb_lock->clist);
spin_unlock(&fp->conn->llist_lock);
}
However, when a client disconnects without SMB2 LOGOFF, ksmbd preserves
durable file handles via session_fd_check(), which sets fp->conn to
NULL and arms the durable scavenger timeout, but does not detach the
byte-range locks from the dying connection's lock list.
When the scavenger timeout expires, ksmbd_durable_scavenger() calls
__ksmbd_close_fd(NULL, fp). At this point fp->conn is NULL and the
original connection object has already been freed by ksmbd_conn_free(),
so it would cause a use-after-free or NULL pointer dereference.
Fix by checking fp->conn for NULL before accessing fp->conn->llist_lock
in the lock cleanup loop.
Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2")
Cc: stable@vger.kernel.org
Signed-off-by: munan Huang <munanevil@gmail.com>
---
fs/smb/server/vfs_cache.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/smb/server/vfs_cache.c b/fs/smb/server/vfs_cache.c
index 168f2dd7e200..772a84d95fe3 100644
--- a/fs/smb/server/vfs_cache.c
+++ b/fs/smb/server/vfs_cache.c
@@ -463,9 +463,11 @@ static void __ksmbd_close_fd(struct ksmbd_file_table *ft, struct ksmbd_file *fp)
* there are not accesses to fp->lock_list.
*/
list_for_each_entry_safe(smb_lock, tmp_lock, &fp->lock_list, flist) {
- spin_lock(&fp->conn->llist_lock);
- list_del(&smb_lock->clist);
- spin_unlock(&fp->conn->llist_lock);
+ if (fp->conn) {
+ spin_lock(&fp->conn->llist_lock);
+ list_del(&smb_lock->clist);
+ spin_unlock(&fp->conn->llist_lock);
+ }
list_del(&smb_lock->flist);
locks_free_lock(smb_lock->fl);
--
2.34.1
next reply other threads:[~2026-04-02 8:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-02 8:39 munan Huang [this message]
2026-04-04 2:28 ` [PATCH] ksmbd: fix use-after-free in __ksmbd_close_fd() lock cleanup Namjae Jeon
2026-04-04 5:02 ` ChenXiaoSong
2026-04-04 14:28 ` Namjae Jeon
2026-04-04 14:59 ` 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=20260402083912.457676-1-munanevil@gmail.com \
--to=munanevil@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=senozhatsky@chromium.org \
--cc=smfrench@gmail.com \
--cc=stable@vger.kernel.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