[PATCH 6.6.y 0/1] ksmbd: validate owner of durable handle on reconnect

Alva Lan posted 1 patch 2 days, 6 hours ago
fs/smb/server/mgmt/user_session.c |  8 +--
fs/smb/server/oplock.c            |  7 +++
fs/smb/server/oplock.h            |  1 +
fs/smb/server/smb2pdu.c           |  3 +-
fs/smb/server/vfs_cache.c         | 90 +++++++++++++++++++++++++++----
fs/smb/server/vfs_cache.h         | 12 ++++-
6 files changed, 105 insertions(+), 16 deletions(-)
[PATCH 6.6.y 0/1] ksmbd: validate owner of durable handle on reconnect
Posted by Alva Lan 2 days, 6 hours ago
Hi,

This patch backports upstream commit 49110a8ce654 ("ksmbd: validate owner
of durable handle on reconnect") to the 6.6.y stable branch to address
CVE-2026-31717.

The vulnerability allows any authenticated user to hijack an orphaned
durable file handle by predicting or brute-forcing the persistent ID.

The fix adds owner identity (UID, GID, account name) tracking to durable
handles and validates it during SMB2_CREATE (DHnC) reconnect, per the
MS-SMB2 specification.

An additional adaptation was needed for 6.6.y: in ksmbd_free_global_file_table(),
the call to ksmbd_destroy_file_table(&global_ft) was replaced with
idr_destroy/kfree, since the function changed to take a
struct ksmbd_session *. This matches the approach in upstream commit
d484d621d40f ("ksmbd: add durable scavenger timer").

Testing:
- Build tested: compiled cleanly on x86_64 with CONFIG_SMB_SERVER=y
- Boot tested: kernel 6.6.140 boots and ksmbd serves shares normally
- Functional test: verified using a Python SMB2 test client that:
  1. Legitimate owner (user_a) can reconnect to own durable handle (PASS)
  2. Different user (user_b) is rejected when attempting DHnC reconnect
     with user_a's persistent file ID (PASS - STATUS_OBJECT_NAME_NOT_FOUND)
- Regression test: normal SMB operations (upload, download, delete, mkdir)
  work correctly for both users

Thanks,
Alva Lan

Namjae Jeon (1):
  ksmbd: validate owner of durable handle on reconnect

 fs/smb/server/mgmt/user_session.c |  8 +--
 fs/smb/server/oplock.c            |  7 +++
 fs/smb/server/oplock.h            |  1 +
 fs/smb/server/smb2pdu.c           |  3 +-
 fs/smb/server/vfs_cache.c         | 90 +++++++++++++++++++++++++++----
 fs/smb/server/vfs_cache.h         | 12 ++++-
 6 files changed, 105 insertions(+), 16 deletions(-)

-- 
2.43.0
Re: [PATCH 6.6.y 0/1] ksmbd: validate owner of durable handle on reconnect
Posted by Namjae Jeon 2 hours ago
Hi Alva,

> An additional adaptation was needed for 6.6.y: in ksmbd_free_global_file_table(),
> the call to ksmbd_destroy_file_table(&global_ft) was replaced with
> idr_destroy/kfree, since the function changed to take a
> struct ksmbd_session *. This matches the approach in upstream commit
> d484d621d40f ("ksmbd: add durable scavenger timer").
I think we should backport the upstream commit d484d621d40f ("ksmbd:
add durable scavenger timer") first, along with any subsequent bug-fix
patches related to it.
Thanks!
Re: [PATCH 6.6.y 0/1] ksmbd: validate owner of durable handle on reconnect
Posted by Sasha Levin 5 hours ago
> This patch backports upstream commit 49110a8ce654 ("ksmbd: validate owner
> of durable handle on reconnect") to the 6.6.y stable branch to address
> CVE-2026-31717.
> [...]
> An additional adaptation was needed for 6.6.y: in ksmbd_free_global_file_table(),
> the call to ksmbd_destroy_file_table(&global_ft) was replaced with
> idr_destroy/kfree, since the function changed to take a
> struct ksmbd_session *. This matches the approach in upstream commit
> d484d621d40f ("ksmbd: add durable scavenger timer").

Thanks for the backport. The 6.12.y version has been queued.

For 6.6.y, the diff isn't a straight cherry-pick and the rewritten
ksmbd_free_global_file_table() path in particular is a non-trivial
stable-only adaptation. Before I queue this for 6.6.y, could you get
Acks from the ksmbd maintainers on the 6.6.y diff specifically? In
particular:

  Namjae Jeon <linkinjeon@kernel.org>
  Steve French <stfrench@microsoft.com>

Once one of them has Ack'd the 6.6 adaptation I'll pick it up.

-- 
Thanks,
Sasha