Re: [PATCH] nfsd: fix replay buffer length underflow in nfsd4_encode_operation

["Chuck Lever" <cel@kernel.org>]

On Sun, Apr 12, 2026, at 6:01 AM, Xiaobo Liu wrote:
> When nfsd4_encode_operation() truncates the reply back to
> op_status_offset + XDR_UNIT, the replay-cache path may still try to
> compute the encoded payload length from xdr->buf->len.

It seems to me that this sequence cannot actually occur.  The
xdr_truncate_encode() call and the replay-cache length computation
are in mutually exclusive branches of an if/else-if chain in
nfsd4_encode_operation():

  if (op->status == nfserr_resource ||
      op->status == nfserr_rep_too_big ||
      op->status == nfserr_rep_too_big_to_cache) {
          ...
          xdr_truncate_encode(xdr, op_status_offset + XDR_UNIT);
  } else if (so) {
          /* replay-cache length computation here */
  }

The replay-cache path only executes when the truncation path does
not. The commit message describes a flow where both execute, but
the else-if prevents that.


> If xdr->buf->len is smaller than op_status_offset + XDR_UNIT, the
> subtraction underflows

Is this condition reachable?  op_status_offset is captured from
xdr->buf->len before xdr_reserve_space(xdr, XDR_UNIT) at the top
of the function. After the reserve succeeds, buf->len is at least
op_status_offset + XDR_UNIT. The encoder called at line

  op->status = encoder(resp, op->status, &op->u);

only adds data to the buffer. Encoders that internally truncate
(e.g. nfsd4_encode_readdir) truncate to their own starting_len,
which is recorded after the opnum and status are already encoded,
so buf->len stays >= op_status_offset + XDR_UNIT. After
xdr_commit_encode(), the invariant still holds.

The underflow condition appears structurally impossible on this
code path.


-- 
Chuck Lever