[PATCH 0/2] nfsd: fix a slab overwrite in the NFSv4.1 session reply cache

[Chuck Lever <cel@kernel.org>]

A client that can establish a session can negotiate
ca_maxresponsesize_cached down to NFSD_MIN_HDR_SEQ_SZ, which leaves
every slot's sl_data[] zero bytes long, and then send a cachethis
SEQUENCE whose COMPOUND tag fills the narrowed reply buffer. The
SEQUENCE result is never encoded, cstate.data_offset stays zero, and
the whole reply is copied past the end of the slot. Jérémy Jean found
this and reported it privately, with a KUnit fixture that reproduces
the write under KASAN. The fixture is not part of this series.

nfsd4_store_cache_entry() derives the length to copy from
cstate.data_offset and never compares it against what the slot was
allocated. Clamping the copy there would stop the write, but the slot
would then hold a truncated reply that a retry replays as a complete
one, and the slot seqid has already been consumed by that point.
RFC 8881 Section 2.10.6.1.2 requires an error returned from SEQUENCE
to leave the slot untouched, so the size has to be settled before the
slot is accepted. The copy in nfsd4_store_cache_entry() is left as it
stands.

The new check runs ahead of xdr_restrict_buflen(), which fails only
once the headers and tag alone overrun the negotiated limit. Adding
the fixed-size SEQUENCE result on top of them also rejects a request
that leaves no room for the reply the client asked to have cached.
Such a request cannot produce a complete reply today either.

---
Chuck Lever (1):
      nfsd: set op->status when an operation's header cannot be encoded

Jérémy Jean (1):
      nfsd: preflight SEQUENCE replies before accepting a slot

 fs/nfsd/nfs4state.c | 19 ++++++++++++++++++-
 fs/nfsd/nfs4xdr.c   | 13 +++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
---
base-commit: 76427d869120552a1a82e1f1488d9f8311827d84
change-id: 20260815-jean-70ae7975e5a1

Best regards,
--  
Chuck Lever