data built 2026-10-19T13:16:53Z

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

7.5 EPSS 0.5% AV:N

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

ReleaseStatus VersionWhat this means
Debian 12bookwormfixed6.1.177-1Update the kernel and reboot. Fixed in 6.1.177-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixiefixed6.12.95-1Update the kernel and reboot. Fixed in 6.12.95-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.3-1Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.3-1Update 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 nfsv4

Prints 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

IntroducedFixed inCommit
4.05.15.21176b94cbd32aa
4.06.1.177c8e4e0c701d0
4.06.6.1446c344fff2fef
4.06.12.95427ab81a811d
4.06.18.38012d37a568bf
4.07.1.330aae62e50b4
4.07.241fe0f7b84f0

Debian advisories

AdvisoryDateShipped toDebian
DLA-4700-12026-07-26bullseye 6.1.177-1~deb11u1tracker

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).