A vulnerability was found in NFS-Ganesha's core NFSv4.1 compound dispatcher. When a COMPOUND request includes a SEQUENCE operation with sa_cachethis=TRUE and a READ operation, the zero-copy READ buffer is freed when the reply is first transmitted. However, the NFSv4.1 session-slot reply cache stores the reply object by shallow pointer, retaining a dangling reference to the freed buffer.

RFC 5661 §2.10.6.2 permits a client to resend the same slot ID and sequence ID as a legal replay. When the server handles such a replay, it re-encodes the freed READ buffer onto the wire (use-after-free read, disclosing heap contents to the remote client) and frees the same pointer again on send completion (double-free, corrupting the allocator and crashing the daemon). The replay count is unbounded.

The bug is in the FSAL-independent core (nfs4_op_read.c, rpc_tools.c, nfs4_Compound.c, nfs4_op_sequence.c), so every FSAL backend (VFS, CEPH, GLUSTER, RGW, MEM) is affected. The vulnerability was introduced in commit 48e5220b2 ("Make read path use iovec all the way through"), first released in V6.0. V5.9 and earlier are not affected.

On AUTH_SYS/AUTH_NONE exports (the common default), no real credential is required — the client asserts any uid. The attack is deterministic (not a race condition) and requires only TCP reachability to the NFS port. An end-to-end PoC establishes an NFSv4.1 session, creates a file, issues a cached READ, and triggers the crash in a single shot.

Impact:
- Remote denial of service: double-free corrupts the heap allocator and crashes ganesha.nfsd. Trivially sustained as a crash-loop on restart.
- Remote heap information disclosure: each replay re-encodes a freed, potentially reoccupied heap chunk of attacker-controlled size and sends it to the client.

Upstream: unfixed as of V15.9 (current tip of the next branch).