NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.38, and 1 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From 6b7f3cf96364eaf597940cb5c68a682894829915 · fixed in 76b94cbd32aacf36a641956385a852635c6802b9; From 6b7f3cf96364eaf597940cb5c68a682894829915 · fixed in c8e4e0c701d0192a2efb6df059c0f9e19678c23d; From 6b7f3cf96364eaf597940cb5c68a682894829915 · fixed in 6c344fff2feff9d4d716d8e4ad40e9b5040ee5ea; From 6b7f3cf96364eaf597940cb5c68a682894829915 · fixed in 427ab81a811dab4bca9d19f82eec5847ae42646e; From 6b7f3cf96364eaf597940cb5c68a682894829915 · fixed in 012d37a568bfbb2c9686f03ade75560bc7139956; From 6b7f3cf96364eaf597940cb5c68a682894829915 · fixed in 30aae62e50b4e074a90a9a5e15246548fbdc1182; From 6b7f3cf96364eaf597940cb5c68a682894829915 · fixed in 41fe0f7b84f0cb822ae10ab08592996a592b2a25
- Linux Linux
4.0
- KernelLinux
From 4.0.0 · fixed in 5.15.211; From 5.16.0 · fixed in 6.1.177; From 6.2.0 · fixed in 6.6.144; From 6.7.0 · fixed in 6.12.95; From 6.13.0 · fixed in 6.18.38; From 6.19.0 · fixed in 7.1.3
References 7
git.kernel.org
- stable/c/76b94cbd32aacf36a641956385a852635c6802b9
- stable/c/c8e4e0c701d0192a2efb6df059c0f9e19678c23d
- stable/c/6c344fff2feff9d4d716d8e4ad40e9b5040ee5ea
- stable/c/427ab81a811dab4bca9d19f82eec5847ae42646e
- stable/c/012d37a568bfbb2c9686f03ade75560bc7139956
- stable/c/30aae62e50b4e074a90a9a5e15246548fbdc1182
- stable/c/41fe0f7b84f0cb822ae10ab08592996a592b2a25