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

Look up another CVE · open CVE-2026-53399 in the interactive tracker

CVE-2026-53399

nfsd: release layout stid on setlease failure

9.8 EPSS 0.5% AV:N

Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem fs/nfsd. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-53399 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 12bookwormfixedDLA-4720-1 · 2026-08-05 · text6.1.180-1Update the kernel and reboot. DLA-4720-1 shipped the fix on 2026-08-05, in 6.1.180-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixiefixedDSA-6393-1 · 2026-07-21 · text6.12.96-1Update the kernel and reboot. DSA-6393-1 shipped the fix on 2026-07-21, in 6.12.96-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.
Debian 12bookworm · linux-6.12fixedDLA-4724-1 · 2026-08-07 · text6.12.100-1~deb12u1Update the kernel and reboot. DLA-4724-1 shipped the fix on 2026-08-07, in 6.12.100-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).

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/nfs4layouts.c

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

Check it on the machine

grep -wE 'CONFIG_NFSD|CONFIG_NFSD_PNFS' /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 nfsd

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, sid, bookworm · linux-6.12m
m
a loadable module on every flavour - check lsmod, can be blacklisted
Build switches
CONFIG_NFSD, CONFIG_NFSD_PNFS
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
9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector
network (AV:N)source
EPSS
0.54%, higher than 44.4% 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

IntroducedFixed inCommit
4.05.10.261d788ef40a751
4.05.15.2122e0a5d6d6260
4.06.1.1787bbb7ce74051
4.06.6.14548a586e382e4
4.06.12.96d369e5edfaaf
4.06.18.398dee7c278f1c
4.07.1.383c2b7797742
4.07.230d55c8aabb2

Debian advisories

AdvisoryDateShipped toDebian
DLA-4724-12026-08-07bookworm 6.12.100-1~deb12u1tracker
DLA-4723-12026-08-07bullseye 6.1.180-1~deb11u1tracker
DLA-4720-12026-08-05bookworm 6.1.180-1tracker
DLA-4717-12026-08-05bullseye 5.10.262-1tracker
DSA-6393-12026-07-21trixie 6.12.96-1tracker

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 bug is reached through nfsd's NFSv4 OP_LAYOUTGET handler, which processes attacker-controlled RPC compounds over the network on TCP port 2049.
AC:LAttack complexity, low
An authenticated NFS client can reliably trigger the fault by issuing LAYOUTGET on block/SCSI pNFS exports so that nfsd4_layout_setlease() fails (e.g., -ENOMEM or -EINVAL), and can retry, spray the slab, and race concurrent compounds to exploit the dangling IDR entry.
PR:NPrivileges required, none
Exploitation requires only the ability to act as a remote NFSv4 client against an export with pNFS enabled, not local shell access or elevated privileges on the Linux host.
UI:NUser interaction, none
No end-user or administrator action on the server is required; the vulnerability is triggered entirely through malicious NFS protocol traffic from a network client.
S:UScope, unchanged
Impact is confined to kernel memory corruption and nfsd state within the same kernel security boundary, not a cross-boundary escape such as VM or container breakout.
C:HConfidentiality impact, high
The IDR retains a pointer to freed layout stateid slab memory, creating a use-after-free that can be leveraged for arbitrary kernel memory reads after heap reuse.
I:HIntegrity impact, high
UAF on the layout stateid object enables controlled slab reuse and corruption of adjacent kernel structures, supporting arbitrary write or control-flow hijack primitives.
A:HAvailability impact, high
Dereferencing the dangling IDR pointer during state iteration or stateid lookup can cause kernel oops/panic, and UAF exploitation can crash or hang the server.