In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE

FSCTLSETSPARSE in fsctlsetsparse() modifies the file's sparse attribute and saves it through xattr without any permission checks.

This exposes two issues:

1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check testtreeconnflag(work->tcon, KSMBDTREECONNFLAGWRITABLE), but FSCTLSETSPARSE does not.

2) Even on writable shares, clients without FILEWRITEDATA or FILEWRITEATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here.

Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix potencial OOB in getfileallinfo() for compound requests

When a compound request consists of QUERYDIRECTORY + QUERYINFO (FILEALLINFORMATION) and the first command consumes nearly the entire maxtranssize, getfileallinfo() would blindly call smbConvertToUTF16() with PATHMAX, causing out-of-bounds write beyond the response buffer. In getfileallinfo(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2fileallinfo structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2calcmaxoutbuflen() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATHMAX) to ensure a safe copy operation.

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix OOB write in QUERYINFO for compound requests

When a compound request such as READ + QUERYINFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.

The root cause was that smb2getinfosec() checked buffer space using ppntsdsize from xattr, while buildsecdesc() often synthesized a significantly larger descriptor from POSIX ACLs.

This patch introduces smbaclsecdescscratchlen() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2calcmaxoutbuflen(), and uses exact-sized allocation + iov pinning.

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: validate owner of durable handle on reconnect

Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.

According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durableowner structure to ksmbdfile to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbdvfscomparedurableowner() to validate the identity of the requester during SMB2CREATE (DHnC).

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: validate inherited ACE SID length

smbinheritdacl() walks the parent directory DACL loaded from the security descriptor xattr. It verifies that each ACE contains the fixed SID header before using it, but does not verify that the variable-length SID described by sid.numsubauth is fully contained in the ACE.

A malformed inheritable ACE can advertise more subauthorities than are present in the ACE. comparesids() may then read past the ACE. smbsetace() also clamps the copied destination SID, but used the unchecked source SID count to compute the inherited ACE size. That could advance the temporary inherited ACE buffer pointer and ntsize accounting past the allocated buffer.

Fix this by validating the parent ACE SID count and SID length before using the SID during inheritance. Compute the inherited ACE size from the copied SID so the size matches the bounded destination SID. Reject the inherited DACL if size accumulation would overflow smbacl.size or the security descriptor allocation size.

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: scope conn->binding slowpath to bound sessions only

When the binding SESSIONSETUP sets conn->binding = true, the flag stays set after the call so that the global session lookup in ksmbdsessionlookupall() can find the session, which was not added to conn->sessions. Because the flag is connection-wide, the global lookup path will also resolve any other session by id if asked.

Tighten the global lookup so that the returned session must have this connection registered in its channel xarray (sess->ksmbdchannlist). The channel entry is installed by the existing bindingsession path in ntlmauthenticate()/krb5authenticate() when a SESSIONSETUP completes successfully, so this condition is a strict equivalent of "this connection has been accepted as a channel of this session". Connections that have not bound to a given session cannot reach it via the global table.

The existing conn->binding gate for entering the slowpath is preserved so that non-binding connections keep the fast-path-only behavior, and the session->state check is unchanged.

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix memory leaks and NULL deref in smb2lock()

smb2lock() has three error handling issues after listdel() detaches smblock from locklist at nocheckcl:

1) If vfslockfile() returns an unexpected error in the non-UNLOCK path, goto out leaks smblock and its flock because the out: handler only iterates locklist and rollbacklist, neither of which contains the detached smblock.

2) If vfslockfile() returns -ENOENT in the UNLOCK path, goto out leaks smblock and flock for the same reason. The error code returned to the dispatcher is also stale.

3) In the rollback path, smbflockinit() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Fix cases 1 and 2 by hoisting the locksfreelock()/kfree() to before the if(!rc) check in the UNLOCK branch so all exit paths share one free site, and by freeing smblock and flock before goto out in the non-UNLOCK branch. Propagate the correct error code in both cases. Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding a NULL check for locksfreelock(rlock) in the shared cleanup.

Found via call-graph analysis using sqry.

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: use volume UUID in FSOBJECTIDINFORMATION

Use sb->suuid for a proper volume identifier as the primary choice. For filesystems that do not provide a UUID, fall back to stfs.ffsid obtained from vfsstatfs().