CVE-2026-53397

What the bug is

nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.

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/nfsd/nfs2acl.c
fs/nfsd/nfs3acl.c

What this is

KERNEL NFSD, SUNRPC, AND LOCKD SERVERSMAINTAINERS section matched on fs/nfsd/ · linux-nfs@vger.kernel.org · Supported

Kernel module

none to look for. The file would have gone into nfsd, and Debian does not compile it into that module, so finding nfsd in lsmod would say nothing about this CVE.

Check it on the machine

grep -wE 'CONFIG_NFSD|CONFIG_NFSD_V2_ACL' /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.

Show whether Debian builds this, per release

Debian does not build this code. In 4 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.

• bookworm, trixie, forky, sidn

n

not enabled on any flavour - this release does not build the code

Build switches

CONFIG_NFSD, CONFIG_NFSD_V2_ACL

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.53%, higher than 43.5% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

fs/nfsd

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.13	5.10.260	b2eb1ffd511d
2.6.13	5.15.211	b94c4be77682
2.6.13	6.1.177	887f92ceccf3
2.6.13	6.6.144	1e96239fddce
2.6.13	6.12.95	bd69a8254851
2.6.13	6.18.38	136b416593f1
2.6.13	7.1.3	a5b42c1e4ff2
2.6.13	7.2	0853ac544c59

Debian advisories