REDHAT-BUG-2502260: Null Pointer Dereference
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: reject zero-length raddr in nfs4decodempdsaddr
nfs4decodempdsaddr() decodes the rnetid and raddr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdrstreamdecodestringdup(), and the current code checks only "nlen < 0" / "rlen < 0" before dereferencing the returned string.
When the on-wire opaque has length zero, xdrstreamdecodeopaqueinline() returns 0 and xdrstreamdecodestringdup() 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue is reachable by pNFS-flexfile clients that mount against a malicious or compromised NFSv4 metadata server. The vulnerable path processes GETDEVICEINFO multipath-DS responses.
What must an attacker do to trigger the failure?
An attacker controlling, or able to tamper with, the metadata server response must provide a GETDEVICEINFO multipath-DS body with a zero-length r_addr opaque. This leaves the decoded address buffer NULL and leads to a NULL pointer dereference when the client searches it for a port separator.
What happens when the malformed response is received?
Affected clients can panic due to a kernel NULL pointer dereference. The resolution rejects zero-length address data as malformed, returning -EBADMSG instead of dereferencing a NULL buffer.