Look up another CVE · open CVE-2026-53391 in the interactive tracker
CVE-2026-53391
NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem fs/nfs. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-53391 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.177-1 | Update the kernel and reboot. Fixed in 6.1.177-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.95-1 | Update the kernel and reboot. Fixed in 6.12.95-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/nfs/pnfs_nfs.c
- What this is
- NFS, SUNRPC, AND LOCKD CLIENTSMAINTAINERS section matched on fs/nfs/ · linux-nfs@vger.kernel.org · Maintained
- Kernel module
- nfsv4
Check it on the machine
grep -wE 'CONFIG_NFS_FS|CONFIG_NFS_V4|CONFIG_NFS_V4_1' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w nfsv4Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_NFS_FS, CONFIG_NFS_V4, CONFIG_NFS_V4_1
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.52%, higher than 42.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/nfs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.0 | 5.15.211 | 76b94cbd32aa |
| 4.0 | 6.1.177 | c8e4e0c701d0 |
| 4.0 | 6.6.144 | 6c344fff2fef |
| 4.0 | 6.12.95 | 427ab81a811d |
| 4.0 | 6.18.38 | 012d37a568bf |
| 4.0 | 7.1.3 | 30aae62e50b4 |
| 4.0 | 7.2 | 41fe0f7b84f0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4700-1 | 2026-07-26 | bullseye 6.1.177-1~deb11u1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The crash is triggered by processing a malicious GETDEVICEINFO RPC response from an NFS metadata server over the network, on the standard NFSv4 client path used by pNFS file and flexfile layouts.
- AC:LAttack complexity, low
- Once a victim is a pNFS client, the attacker reliably triggers the bug by sending a GETDEVICEINFO body with a zero-length r_netid or r_addr opaque; no race or special memory layout is required.
- PR:NPrivileges required, none
- The attacker acts as (or compromises) the remote NFS metadata server and needs no local privileges on the victim client; exploitation is delivered entirely through NFS protocol responses to an already-established mount.
- UI:NUser interaction, none
- In the highest-impact scenario—a compromised enterprise/HPC metadata server or autofs-managed pNFS mount—no further victim action is needed beyond normal file I/O that provokes GETDEVICEINFO.
- S:UScope, unchanged
- The vulnerability causes a kernel panic on the NFS client itself and does not cross a security boundary such as a VM escape or sandbox breakout.
- C:NConfidentiality impact, none
- This is a NULL pointer dereference in strrchr() with no out-of-bounds read or use-after-free; it does not disclose kernel memory or attacker-controlled data.
- I:NIntegrity impact, none
- There is no memory corruption, arbitrary write, or control-flow hijack primitive—only an immediate NULL dereference that terminates kernel execution.
- A:HAvailability impact, high
- The NULL pointer dereference in kernel context causes an oops or panic, fully denying availability of the affected client (and any co-hosted workloads until reboot).