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(-)
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
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!
> 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
© 2016 - 2026 Red Hat, Inc.