Re: [PATCH v4 0/2] ksmbd: fix named-pipe reply loss and operation races

[Namjae Jeon]

On Tue, Oct 27, 2026 at 11:43 PM Wang Zhaolong
<wangzhaolong3@xxxxxxxxxxx> wrote:
>
> This is a candidate v4 of the named-pipe fix series, based on mainline
> 7d37252fc49a. Patch 1 is unchanged from v3. Patch 2 addresses the cached
> TRANSCEIVE input-acceptance problem reported in review and reports
> BUFFER_OVERFLOW for a positive pipe READ that leaves unread reply bytes.
>
> The first problem is that RPC IPC replies are matched only by the pipe
> handle. Concurrent operations can interfere with reply delivery, and
> CLOSE can release the handle before another operation finishes. Patch 1
> adds per-pipe serialization and lifetime, checks teardown after locking,
> and clears pipe state on logoff. Existing mainline foreign-handle checks
> and STATUS_FILE_CLOSED behavior are preserved.
>
> Patch 2 retains the original IPC reply allocation with an offset. READ
> and TRANSCEIVE return only bytes that fit and retain the suffix until it
> is successfully pinned in a response. Closing, logging off or disconnecting
> releases the cached reply.
>
> In v3, TRANSCEIVE with cached data sent a userspace WRITE before returning
> older cached bytes. Mountd's RETURN_READY fast path can acknowledge that
> WRITE without accepting its input. A later transaction can then return an
> old reply while skipping its own input. Merely returning the cache without
> the WRITE would also silently ignore the current transaction's input.
>
> V4 instead rejects TRANSCEIVE with STATUS_PIPE_BUSY before any IPC when
> cached unread data exists. It does not accept input or consume output.
> The client can drain through READ and explicitly resubmit. The no-cache
> path still uses one combined IOCTL IPC. There is no new kernel RPC queue,
> extra whole-reply copy, IPC ABI change, timeout, quota or production limit.
>
> MS-FSCC section 2.3.48 lists PIPE_BUSY for unread pipe data; native Wine
> and ReactOS behavior also supports this rejection. This remains a proposal
> for the SMB2 path, not a claim of a fresh Windows remote-SMB2 oracle or a
> universal MUST. No new per-pipe mode selection is introduced.
>
> Changes in v4:
> - Reject cached TRANSCEIVE with PIPE_BUSY and a standard SMB2 error reply
>   before IPC, preserving the cache and offset.
> - Remove the cached TRANSCEIVE WRITE/ACK path.
> - Set BUFFER_OVERFLOW only after a successful positive-length READ leaves
>   a suffix of the same cached reply; exact final drain returns success.
> - Preserve the zero-length READ no-op and pin-before-consume ordering.
>
> Bugzilla references:
>   222196: short PIPE_TRANSCEIVE output loses unread RPC reply bytes
>   222197: same-pipe RPC replies can reach the wrong request
>
> Wang Zhaolong (2):
>   ksmbd: avoid races between named-pipe operations
>   ksmbd: fix named-pipe reply loss with small output buffers
Applied them to #ksmbd-for-next.
Thanks!