CVE-2026-31402

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix heap overflow in NFSv4.0 LOCK replay cache<br /> <br /> The NFSv4.0 replay cache uses a fixed 112-byte inline buffer<br /> (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.<br /> This size was calculated based on OPEN responses and does not account<br /> for LOCK denied responses, which include the conflicting lock owner as<br /> a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).<br /> <br /> When a LOCK operation is denied due to a conflict with an existing lock<br /> that has a large owner, nfsd4_encode_operation() copies the full encoded<br /> response into the undersized replay buffer via read_bytes_from_xdr_buf()<br /> with no bounds check. This results in a slab-out-of-bounds write of up<br /> to 944 bytes past the end of the buffer, corrupting adjacent heap memory.<br /> <br /> This can be triggered remotely by an unauthenticated attacker with two<br /> cooperating NFSv4.0 clients: one sets a lock with a large owner string,<br /> then the other requests a conflicting lock to provoke the denial.<br /> <br /> We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full<br /> opaque, but that would increase the size of every stateowner, when most<br /> lockowners are not that large.<br /> <br /> Instead, fix this by checking the encoded response length against<br /> NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the<br /> response is too large, set rp_buflen to 0 to skip caching the replay<br /> payload. The status is still cached, and the client already received the<br /> correct response on the original request.