CVE-2026-31402: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-31402 Overview

CVE-2026-31402 is a heap overflow vulnerability in the Linux kernel's NFSv4.0 LOCK replay cache implementation. The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This buffer size was calculated based on OPEN responses and does not account for LOCK denied responses, which include a 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 string, 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.

Critical Impact

This vulnerability can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients, potentially leading to kernel memory corruption, denial of service, or privilege escalation.

Affected Products

• Linux Kernel (NFSv4.0 server implementations)
• Systems running NFS server daemon (nfsd) with NFSv4.0 enabled
• Enterprise Linux distributions with vulnerable kernel versions

Discovery Timeline

• 2026-04-03 - CVE CVE-2026-31402 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-31402

Vulnerability Analysis

The vulnerability exists in the NFSv4.0 replay cache mechanism within the Linux kernel's nfsd subsystem. The replay cache is designed to handle idempotent request retransmissions by storing previously encoded responses for potential replay. However, the fixed buffer size of 112 bytes (NFSD4_REPLAY_ISIZE) was designed with OPEN operation responses in mind and fails to accommodate the larger LOCK denied responses.

When an NFSv4.0 LOCK operation results in a denial due to conflicting locks, the response must include the conflicting lock owner information. The NFSv4 protocol allows lock owners to be opaque data up to 1024 bytes (NFS4_OPAQUE_LIMIT). The nfsd4_encode_operation() function attempts to copy this potentially oversized response into the undersized replay buffer without performing adequate bounds checking, leading to a classic heap buffer overflow condition.

Root Cause

The root cause is a buffer size miscalculation in the NFSv4.0 replay cache design. The NFSD4_REPLAY_ISIZE constant was set to 112 bytes based on the expected size of OPEN operation responses, without considering that LOCK denied responses can be significantly larger due to the variable-length lock owner field. The absence of bounds checking in read_bytes_from_xdr_buf() when copying into the replay buffer allows the overflow to occur.

Attack Vector

The attack can be executed remotely by an unauthenticated attacker using two cooperating NFSv4.0 clients:

1. The first client establishes a lock on a file with a large owner string (up to 1024 bytes)
2. The second client requests a conflicting lock on the same file region
3. The NFS server denies the lock request and attempts to cache the denial response, including the large lock owner from the conflicting lock
4. The oversized response overflows the 112-byte replay buffer, corrupting up to 944 bytes of adjacent heap memory

This attack requires only network access to an NFSv4.0 server and does not require any authentication credentials.

Detection Methods for CVE-2026-31402

Indicators of Compromise

• Kernel panic or crash events originating from nfsd or slab allocator subsystems
• Unusual NFS client connections establishing locks with abnormally large owner strings (approaching 1024 bytes)
• Memory corruption signatures in kernel logs referencing nfsd stateowner structures
• Slab corruption warnings or KASAN reports indicating out-of-bounds writes in nfsd-related slabs

Detection Strategies

• Monitor kernel logs for slab-out-of-bounds write warnings related to nfsd operations
• Implement network monitoring for NFSv4 LOCK operations with oversized owner fields
• Deploy kernel memory debugging tools (KASAN, KFENCE) to detect heap corruption in test environments
• Use NFS traffic analysis to identify suspicious patterns of lock acquisition followed by conflicting lock requests

Monitoring Recommendations

• Enable kernel memory sanitizers in development and staging environments to detect heap corruption
• Configure alerting for nfsd service crashes or unexpected restarts
• Monitor network traffic to NFS servers for unusual client behavior patterns
• Implement audit logging for NFSv4 lock operations to enable forensic analysis

How to Mitigate CVE-2026-31402

Immediate Actions Required

• Apply the kernel patches from the stable kernel trees immediately
• Consider temporarily disabling NFSv4.0 support and using NFSv4.1+ if operationally feasible
• Restrict network access to NFS servers to trusted clients only
• Implement firewall rules to limit NFS exposure to known, authorized clients

Patch Information

The Linux kernel developers have released fixes across multiple stable kernel branches. The patch adds a bounds check to verify the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response exceeds the buffer size, rp_buflen is set to 0 to skip caching the replay payload while still caching the status.

The following kernel git commits contain the fix:

• Kernel Git Commit 0f0e2a5
• Kernel Git Commit 5133b61
• Kernel Git Commit 8afb437
• Kernel Git Commit ae84983
• Kernel Git Commit c9452c0
• Kernel Git Commit dad0c3c

Workarounds

• Restrict NFSv4.0 access to only trusted clients through firewall rules and NFS export options
• Consider using NFSv4.1 or newer which may have different replay cache implementations
• Implement network segmentation to isolate NFS servers from untrusted network segments
• Monitor and limit the maximum lock owner size accepted by NFS clients if possible through client-side configuration

# Restrict NFS server access via iptables (example)
iptables -A INPUT -p tcp --dport 2049 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 2049 -j DROP

# Configure NFS exports to restrict client access
# In /etc/exports, limit to trusted subnets:
# /export/data 192.168.1.0/24(rw,sync,no_subtree_check)