[PATCH 0/8] ksmbd: follow-up fixes to previously-merged patches

From: Gael Blivet <[email protected]>

Follow-ups to bugs found in patches from an earlier series ("ksmbd: fix
several independent bugs found while adding Time Machine/AAPL support",
already applied to this tree), plus a few additional issues found while
re-reviewing that same area of code. None of this depends on or touches
the AAPL/Time Machine feature series (sent separately as "ksmbd: add
macOS Time Machine / AAPL SMB2 extension support").

Patches 1, 2, and 4-8 are Sashiko (automated LLM-based patch review)
findings against the original series -- two triaged and fixed
already, the rest found on a closer re-read of that same review this
session:
 - Patch 1: commit 78380c12125a ("ksmbd: route stream
   FileDispositionInformation through stream delete flag") used an
   inode-wide flag to track a per-handle delete-pending state, so
   closing one stream handle could delete a different, unrelated
   stream on the same file.
 - Patch 2: commit bb682f1496f7 ("ksmbd: quiet mdssvc RPC log spam")
   silenced one of two log sites for the same rejected RPC pipe,
   missing a second, separate pr_err() in the caller.
 - Patch 4: two IOCTL response handlers (FSCTL_CREATE_OR_GET_OBJECT_ID,
   FSCTL_GET_REPARSE_POINT) write a fixed-size response without
   checking the actual remaining output buffer space first, unlike
   every comparable case in the same switch statement -- a compound
   SMB2 request that leaves little space for a trailing one of these
   IOCTLs can overflow past the end of the response buffer.
 - Patch 5: stream enumeration (FileStreamInformation) reports each
   stream's name length as its data size, the same bug class already
   fixed for EndOfFile/AllocationSize on an open stream handle, just
   missed at this second site.
 - Patch 6: a DOS attribute struct is used without zero-initializing
   it first; one of its fields is only populated by the on-disk NDR
   decoder for one xattr version, so an older-format xattr leaves
   uninitialized kernel stack memory copied into server state that's
   later exposed to clients via QUERY_INFO.
 - Patch 7: deleting a stream (not the file itself) on a directory
   incorrectly fails with -EBUSY if the directory happens to be
   non-empty, since the emptiness check doesn't distinguish a stream
   handle from the directory handle it's attached to.
 - Patch 8: opening a stream with an AllocationSize create context
   fallocates storage on the underlying base file's actual data,
   since streams don't have their own file and fallocate doesn't
   apply to them.

Patch 3 is unrelated to Sashiko: a 1000x units bug in the default
durable-handle-v2 timeout (60 instead of 60000 milliseconds) that
would make any client relying on the server's default timeout lose
the reconnect race after even a brief disconnect, found during a
separate investigation into durable-handle-v2 reconnect reliability.

Gael Blivet (8):
  ksmbd: route stream FileDispositionInformation through stream delete
    flag
  ksmbd: quiet mdssvc RPC log spam in create_smb2_pipe
  ksmbd: fix durable handle v2 default timeout units (60 -> 60000)
  ksmbd: validate out_buf_len before FSCTL_CREATE_OR_GET_OBJECT_ID and
    FSCTL_GET_REPARSE_POINT writes
  ksmbd: report actual xattr value length in stream enumeration
  ksmbd: zero-initialize xattr_dos_attrib in smb2_update_xattrs()
  ksmbd: don't check directory emptiness when deleting a stream
  ksmbd: skip fallocate for SMB2_CREATE_ALLOCATION_SIZE on a stream
    handle

 fs/smb/server/smb2pdu.c   | 77 ++++++++++++++++++++++++++++++++-------
 fs/smb/server/vfs_cache.c | 49 +++++++++++++++++--------
 fs/smb/server/vfs_cache.h |  7 ++++
 3 files changed, 104 insertions(+), 29 deletions(-)

-- 
2.43.0