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

On Thu, Jul 9, 2026 at 9:06 AM Gaël Blivet-Bailly <[email protected]> wrote:
>
> 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
Applied them except 0002, 0005 patch to #ksmbd-for-next-next.
You can send the updated two patches to me and the list next time.
Thanks!