CVE-2026-31402: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-31402 is a heap overflow vulnerability in the Linux kernel's NFSv4.0 LOCK replay cache, classified as an out-of-bounds write (CWE-787). The flaw exists in the nfsd subsystem, where a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) is used to store encoded operation responses, but is insufficient to hold LOCK denied responses that include variable-length lock owner fields up to 1024 bytes. The vulnerability affects Linux kernel versions from 2.6.12 through multiple stable branches, with fixed versions including those before 5.10.253, 6.1.167, 6.6.130, 6.12.78, 6.18.20, and 6.19.10. It was published on April 3, 2026, and carries a CVSS v3.1 base score of 9.8 (Critical) (GitHub Advisory).

The root cause is an out-of-bounds write (CWE-787) in the NFSv4.0 replay cache handling within the Linux kernel's nfsd subsystem. When a LOCK operation is denied due to a conflicting lock with a large owner string, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() without performing any bounds check. Since LOCK denied responses include the conflicting lock owner as a variable-length opaque field up to NFS4_OPAQUE_LIMIT (1024 bytes), but the buffer is only 112 bytes (NFSD4_REPLAY_ISIZE), this results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer. The attack requires no authentication and can be triggered remotely using two cooperating NFSv4.0 clients: one establishes a lock with a large owner string, and the second requests a conflicting lock to provoke the oversized denial response (GitHub Advisory).

Successful exploitation corrupts adjacent heap memory, which can lead to memory corruption, heap metadata tampering, denial of service, or potential remote code execution depending on what heap objects are adjacent to the replay buffer at the time of the write. All three security pillars are affected: confidentiality (potential data exposure from corrupted memory), integrity (heap corruption enabling arbitrary writes), and availability (kernel crash or instability). Because the attack is network-reachable and requires no privileges, any Linux system running an exposed NFSv4.0 server is at risk of complete kernel compromise (GitHub Advisory).

As of the time of this report, there is no public proof-of-concept exploit and no confirmed in-the-wild exploitation (GitHub Advisory). The EPSS score is approximately 0.036% (per Feedly data), indicating a currently low probability of exploitation within the next 30 days, though the GitHub Advisory Database lists it at 0.206% (43rd percentile). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been identified. Despite the lack of active exploitation, the unauthenticated, network-accessible attack vector and critical CVSS score make this a high-priority patching target.

1. Reconnaissance: Identify Linux servers exposing NFSv4.0 services (typically TCP port 2049) using network scanners such as Nmap (nmap -p 2049 --script nfs-showmount <target>) to confirm NFSv4.0 is enabled.
2. Setup cooperating clients: Prepare two NFSv4.0 client systems that can mount the target NFS export. No authentication credentials are required if the export is accessible to unauthenticated clients.
3. Establish lock with large owner: From Client A, mount the NFS share and acquire a byte-range lock on a file using an NFSv4.0 LOCK request with a crafted lock owner string at or near the maximum opaque limit (up to 1024 bytes, e.g., NFS4_OPAQUE_LIMIT).
4. Trigger conflicting lock: From Client B, mount the same NFS share and request a conflicting byte-range lock on the same file region. The server will deny the lock and generate a LOCK denied response that includes the large owner string from Client A's lock.
5. Trigger heap overflow: The server's nfsd4_encode_operation() copies the oversized LOCK denied response (potentially up to ~1136 bytes) into the 112-byte rp_ibuf replay buffer without bounds checking, writing up to 944 bytes past the buffer end and corrupting adjacent heap memory.
6. Achieve objective: Depending on heap layout, the corruption may cause a kernel panic (denial of service), or with heap grooming techniques, could be leveraged for privilege escalation or remote code execution on the NFS server (GitHub Advisory).

• Network: Unusual or repeated NFSv4.0 LOCK requests (RPC program 100003, procedure LOCK) from two distinct client IPs targeting the same file; NFS traffic containing abnormally large lock owner opaque fields (approaching 1024 bytes) in LOCK or LOCK denied responses.
• Logs: Kernel logs (/var/log/kern.log, dmesg) showing slab-out-of-bounds write errors, kernel BUG/OOPS/panic messages referencing nfsd4_encode_operation or read_bytes_from_xdr_buf; NFS server logs showing repeated LOCK denied responses to the same client pair.
• Process/System: Unexpected kernel crashes or reboots on the NFS server; memory corruption symptoms such as random process crashes or filesystem inconsistencies following NFS LOCK activity.
• File System: Kernel crash dump files (/var/crash/, vmcore) generated around the time of suspicious NFS activity, which may contain evidence of the heap overflow.

Apply the available kernel patches, which fix the issue by validating the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer; if the response is too large, rp_buflen is set to 0 to skip caching the replay payload while still caching the status. Fixed versions include Linux kernel stable releases: before 5.10.253, 6.1.167, 6.6.130, 6.12.78, 6.18.20, and 6.19.10. Patches are available via the kernel stable tree and have been incorporated into vendor updates from Red Hat (RHSA-2026:10108 and subsequent advisories), Amazon Linux 2023, SUSE, AlmaLinux, Rocky Linux, Oracle Linux, and Debian (GitHub Advisory). As an interim workaround if patching is not immediately possible, restrict NFSv4.0 access to trusted client IP addresses using firewall rules or NFS export controls, or disable NFSv4.0 entirely if it is not required by the environment.

The vulnerability was noted in the kernel CVE announcement mailing list (lore.kernel.org) shortly after disclosure on April 3, 2026. Multiple Linux distribution vendors — including Red Hat, SUSE, AlmaLinux, Rocky Linux, Oracle Linux, Amazon Linux, and Debian — have issued security advisories and updated kernel packages. The Yocto Project security mailing list also flagged the issue for embedded Linux users. A blog post on infinitsec.net provided a technical summary shortly after disclosure. The vulnerability has attracted attention due to its notable attribution to Anthropic's Claude AI model in discovering it, with several community discussions and GitHub commits tracking Anthropic-credited CVEs referencing CVE-2026-31402.