CVE-2026-53391 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr
nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only "nlen < 0" / "rlen < 0" before dereferencing the returned string.
When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its "*str = NULL; return ret" tail, leaving buf NULL with a return value of 0. The "< 0" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server.
Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the Linux kernel's Network File System version 4 implementation, specifically affecting the pNFS (parallel NFS) flexible file layout functionality. The issue resides in the nfs4_decode_mp_ds_addr() function which processes network address information from GETDEVICEINFO multipath-DS responses. When a malicious or compromised metadata server sends a zero-length r_addr field in the network address opaque data structure, the decoding process fails to properly validate input parameters before attempting to process the data.
The technical flaw occurs during the decoding of network address opaques where the function uses xdr_stream_decode_string_dup() to extract both r_netid and r_addr values from the GETDEVICEINFO response body. The current implementation only checks for negative length values through "nlen < 0" or "rlen < 0" comparisons, which fails to account for zero-length inputs that are perfectly valid wire protocol constructs. When xdr_stream_decode_opaque_inline() encounters a zero-length opaque, it returns 0 and the subsequent xdr_stream_decode_string_dup() function sets *str = NULL while returning 0, effectively leaving buf as a null pointer. This null pointer dereference becomes exploitable when the code immediately calls strrchr(buf, '.') without any additional validation checks.
The operational impact of this vulnerability is severe as it allows remote attackers to trigger kernel NULL pointer dereferences through specially crafted responses from malicious metadata servers. Any pNFS-flexfile client that mounts against such compromised servers can experience kernel panics and system crashes, effectively enabling denial-of-service attacks against the client systems. This vulnerability directly maps to CWE-476 which describes NULL Pointer Dereference, and aligns with ATT&CK technique T1499.002 for Network Denial of Service by exploiting kernel-level vulnerabilities in network protocols.
The mitigation strategy involves explicitly checking for zero-length cases in the nfs4_decode_mp_ds_addr() function before attempting to process the decoded strings. The fix requires modifying the validation logic to reject zero-length r_addr and r_netid fields, causing the decoder to return -EBADMSG instead of proceeding with null pointer dereference operations. This approach treats malformed GETDEVICEINFO responses as protocol violations rather than allowing kernel crashes. The solution follows best practices for input validation and aligns with defensive programming principles that emphasize early detection and graceful handling of malformed inputs in kernel space code, preventing potential exploitation scenarios while maintaining proper protocol compliance and system stability.