CVE-2026-53391: Linux Kernel pNFS DoS Vulnerability

CVE-2026-53391 Overview

CVE-2026-53391 is a NULL pointer dereference vulnerability in the Linux kernel's NFSv4/pNFS flexfile client. The flaw resides in nfs4_decode_mp_ds_addr(), which processes GETDEVICEINFO multipath data-server responses. When a malicious or compromised metadata server returns a zero-length r_addr or r_netid opaque, xdr_stream_decode_string_dup() leaves the target buffer as NULL with a return value of 0. The subsequent strrchr(NULL, '.') call triggers a kernel NULL pointer dereference, panicking the client.

Critical Impact
Any Linux client mounted with pNFS flexfile against a hostile metadata server can be crashed remotely, causing kernel-level denial of service.

Affected Products

Linux kernel NFSv4/pNFS client (flexfile layout)
Multiple stable kernel branches receiving backports across seven upstream commits
Systems mounting NFSv4.1+ shares with pNFS flexfile layouts

Discovery Timeline

2026-07-19 - CVE-2026-53391 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-53391

Vulnerability Analysis

The defect exists in the nfs4_decode_mp_ds_addr() function within the Linux kernel NFSv4/pNFS flexfile client code path. The function decodes two opaque fields, r_netid and r_addr, from a netaddr4 structure delivered inside a GETDEVICEINFO multipath data-server body. Both decodes rely on xdr_stream_decode_string_dup(), and the caller inspects only the signed length return using an nlen < 0 / rlen < 0 check before dereferencing the returned string pointer.

When the on-wire opaque carries a length of zero, xdr_stream_decode_opaque_inline() returns 0. xdr_stream_decode_string_dup() then falls through to its *str = NULL; return ret tail, producing a NULL buffer with a non-negative return value. The existing sign check does not catch this state. Execution proceeds to strrchr(buf, '.'), which dereferences NULL and causes a kernel oops.

Root Cause

The root cause is missing input validation on the length of decoded XDR opaque fields. The code treats "non-negative" as "valid pointer," while the decoder's contract allows a zero-length input to return a NULL string. This is a classic Null Pointer Dereference issue tied to Improper Input Validation on network-supplied data.

Attack Vector

The attack vector is remote and unauthenticated from the NFS metadata server's perspective. An attacker controlling or impersonating a metadata server that a Linux client has mounted with pNFS flexfile can respond to a GETDEVICEINFO request with a crafted multipath-DS body containing a zero-length r_addr or r_netid opaque. The client kernel dereferences a NULL pointer while parsing the response, halting the client. No credentials or user interaction on the client are required beyond the pre-existing mount.

See the upstream fix at kernel.org commit 427ab81a811d for the corrected decoder logic that rejects zero-length values with -EBADMSG.

Detection Methods for CVE-2026-53391

Indicators of Compromise

Kernel oops or panic messages referencing nfs4_decode_mp_ds_addr or strrchr in the call trace on NFSv4/pNFS client hosts.
Unexpected NFS client reboots or hangs immediately following GETDEVICEINFO RPC traffic to a metadata server.
Malformed GETDEVICEINFO responses observed in packet captures containing zero-length r_netid or r_addr fields.

Detection Strategies

Monitor dmesg, journalctl -k, and /var/log/kern.log for NULL pointer dereference stack traces originating in the NFSv4 client module.
Inspect NFS traffic with tcpdump or wireshark (NFS dissector) for GETDEVICEINFO replies where opaque length fields equal zero.
Correlate NFS client crashes with the specific metadata server and mount point to isolate the offending source.

Monitoring Recommendations

Aggregate kernel crash telemetry from Linux fleets and alert on repeated oops signatures involving nfs4 symbols.
Track kernel package versions across the environment to identify hosts still running vulnerable NFS client code.
Log and review NFS mount targets so that only trusted metadata servers are reachable from production clients.

How to Mitigate CVE-2026-53391

Immediate Actions Required

Apply the vendor-supplied Linux kernel update that includes the upstream fix and reboot affected hosts.
Restrict pNFS flexfile mounts to trusted, authenticated metadata servers on segmented networks.
Audit all NFSv4.1+ clients for unnecessary or legacy mounts pointing at untrusted or externally reachable servers.

Patch Information

The fix explicitly rejects zero-length r_netid and r_addr opaques, returning -EBADMSG so the malformed GETDEVICEINFO body is discarded instead of crashing the client. The change has been merged and backported across multiple stable branches. Reference the upstream commits: 012d37a568bf, 30aae62e50b4, 41fe0f7b84f0, 427ab81a811d, 6c344fff2fef, 76b94cbd32aa, and c8e4e0c701d0.

Workarounds

Avoid the pNFS flexfile layout by mounting NFSv4 shares without pNFS, for example using mount -o vers=4.0 where possible.
Enforce network-level controls (firewalls, VLAN isolation, IPsec) so that only vetted metadata servers can respond to client GETDEVICEINFO calls.
Where feasible, unmount NFSv4/pNFS shares from exposed hosts until the patched kernel is deployed.

bash

# Verify running kernel and NFS client module version
uname -r
modinfo nfsv4 | grep -E 'version|filename'

# Temporary hardening: mount without pNFS flexfile
mount -t nfs4 -o vers=4.0,sec=krb5p server:/export /mnt/nfs