Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-31402 is a critical-severity Out-of-bounds Write (CWE-787) vulnerability in Linux Linux Kernel. Its CVSS base score is 9.8 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation of Remote Services (T1210); ranked in the top 32% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-31402 is a heap overflow vulnerability in the Linux kernel's nfsd implementation for NFSv4.0. The NFSv4.0 replay cache employs a fixed 112-byte inline buffer to store encoded operation responses, sized based on OPEN responses. However, LOCK denied responses include a variable-length conflicting lock owner field up to 1024 bytes, exceeding the buffer capacity. During encoding, nfsd4_encode_operation() copies the full response into the undersized buffer without bounds checking via read_bytes_from_xdr_buf(), resulting in a slab-out-of-bounds write of up to 944 bytes, corrupting adjacent heap memory.
An unauthenticated remote attacker can exploit this vulnerability using two cooperating NFSv4.0 clients. One client sets a lock with a large owner string, while the other requests a conflicting lock, provoking a denial response that triggers the overflow. Successful exploitation leads to arbitrary heap memory corruption, with a CVSS v3.1 base score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), potentially enabling code execution or denial of service on the NFS server.
Patches, available in multiple stable kernel commits such as 0f0e2a54a31a7f9ad2915db99156114872317388 and others linked from kernel.org, mitigate the issue by checking the encoded response length against the NFSD4_REPLAY_ISIZE (112 bytes) before copying into the replay buffer. If the response exceeds this size, the patch sets rp_buflen to 0, skipping caching of the payload while still caching the operation status, ensuring clients receive correct responses without enabling the overflow.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-18786
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based…
more
on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.4.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including fuzzing and bounds checks) finds out-of-bounds write flaws before deployment.
Requiring documented secure-development standards and tools can mandate bounds-checked coding practices that avoid the weakness.
Input validation can structurally reject or sanitize data that would otherwise trigger an out-of-bounds write.
Memory-protection mechanisms limit the exploitability and blast radius of a successful out-of-bounds write.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure-development practices directly require bounds checking and safe memory handling that prevent heap overflows.
Vulnerability scanning and recording can discover out-of-bounds write flaws so they can be remediated.
Patching or replacing vulnerable software directly eliminates known instances of this coding weakness.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance can detect and prevent out-of-bounds write defects.
Secure coding directly addresses out-of-bounds writes through language choice and coding standards.