CVE-2026-53399

What it actually does

This is a Linux kernel use-after-free in the NFS server implementation, specifically in nfsd handling of NFSv4 layout state IDs. During layout state allocation, nfs4_alloc_stid() publishes a state ID into the client IDR before nfsd4_layout_setlease() completes. If setlease fails, the vulnerable error path frees the layout state object directly instead of removing it from the IDR through the normal nfs4_put_stid() teardown path. The IDR can then retain a pointer to freed slab memory, and later IDR traversal paths such as state reporting or client teardown can dereference the stale pointer. Because this occurs in kernel context and is network-reachable through NFS server functionality, impact can include kernel memory corruption, denial of service, information disclosure, and potentially arbitrary code execution depending on exploitability and kernel hardening.

Why it matters to the business

Organizations running affected Linux kernels with the in-kernel NFS server exposed to untrusted or semi-trusted networks could face remote service disruption or host compromise. Successful exploitation may crash file servers, interrupt shared storage access, corrupt active file-serving workloads, or provide an attacker a path to kernel-level control of a system. Although this issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low current EPSS, the CVSS severity is critical because the vulnerable attack surface can be remotely reachable without user interaction.

How an attack unfolds

An attacker targets a Linux system running the vulnerable kernel NFS server. They interact with NFSv4 layout or pNFS-related functionality and trigger a failure in the setlease path after a layout state ID has already been inserted into the client's IDR. The vulnerable cleanup path frees the layout state object without removing its IDR entry, leaving a dangling kernel pointer. The attacker then causes or waits for a later operation that walks the affected IDR, such as NFS state inspection, client teardown, or related nfsd state handling. When the kernel dereferences the stale pointer, it can crash or enter a memory-corruption condition. With sufficient exploit reliability and favorable heap layout, this class of bug may be used for privilege escalation into kernel execution; in less controlled cases, it is more likely to present as a remote kernel panic or NFS service outage.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that contains the nfsd fix for this issue. The corrected code initializes the layout fencing delayed work before setlease and uses nfs4_put_stid() for proper state ID teardown so the IDR entry is removed safely. No exact package-level fixed versions were provided in the input, so remediation should be tracked through vendor advisories for the deployed kernel stream. Where immediate patching is not possible, reduce exposure by disabling the NFS server if not required, restricting access to NFS/RPC services to trusted hosts only, blocking untrusted access to TCP/2049 and associated RPC ports, disabling NFSv4/pNFS functionality if operationally feasible, and ensuring kernel hardening features and crash recovery are enabled.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix, not just that an updated package is installed. Validate by checking the active booted kernel with uname -r and comparing it against the fixed kernel version listed by the Linux distribution or appliance vendor. Confirm whether nfsd is loaded or active using service status checks, loaded module checks, and listening port checks for NFS/RPC services. Where source or build metadata is available, verify the nfsd patch behavior: initialization of ls_fence_work occurs before nfsd4_layout_setlease(), and the setlease-failure path uses nfs4_put_stid(stp) rather than direct kmem_cache_free() cleanup. Exposure is reduced if the host is not running nfsd or if NFS is unreachable from untrusted networks.

Typical attack path

1. Identify a Linux host exposing the in-kernel NFS server, typically on TCP/2049 or related NFS/RPC services.
2. Establish NFSv4 interaction with the server and reach layout state allocation code paths, especially pNFS/NFSv4.1 layout handling.
3. Trigger a setlease failure after nfs4_alloc_stid() has published a new state ID into the client's IDR.
4. Cause the vulnerable cleanup path to free the layout state object while leaving the IDR entry pointing to freed memory.
5. Trigger a subsequent state ID traversal or cleanup path, such as client teardown or state reporting.
6. Leverage the resulting stale-pointer dereference to crash the kernel or attempt controlled kernel memory corruption.

How to detect it

Look for signs of attempted exploitation or successful triggering in kernel, system, and NFS service logs. Primary sources include journalctl/kern.log/messages, nfs-server service logs, audit logs if syscall or service auditing is enabled, crash dumps, kdump/vmcore artifacts, and network telemetry for unusual NFSv4/pNFS activity. Useful evidence includes kernel oops or panic events involving nfsd, KASAN use-after-free reports, slab freelist corruption, general protection faults, stack traces referencing nfsd4_alloc_layout_stateid(), nfsd4_layout_setlease(), nfs4_alloc_stid(), nfs4_put_stid(), nfsd4_free_layout_stateid(), or states_show, and crashes correlated with NFSv4 client connection churn or layout operations. Network detection should focus on unexpected clients issuing NFSv4.1/NFSv4.2 layout-related operations to NFS servers, especially from networks that should not access NFS. There are no known public exploit-specific payload strings from the provided data, so detection should emphasize behavioral anomalies and kernel crash artifacts rather than fixed signatures.

• BUG: KASAN: use-after-free
• KASAN: use-after-free
• use-after-free in nfsd
• general protection fault
• kernel BUG at
• Oops:
• PANIC:
• nfsd4_alloc_layout_stateid
• nfsd4_layout_setlease
• nfs4_alloc_stid
• nfs4_put_stid
• nfsd4_free_layout_stateid
• nfsd4_close_layout
• states_show
• delayed_work_pending
• ls_fence_work
• /proc/fs/nfsd/clients
• nfsd:
• nfs-server.service
• TCP/2049

What your security team should do

• Prioritize patching internet-exposed or broadly reachable Linux NFS servers first, especially systems serving critical shared storage.
• Inventory systems running nfsd and identify hosts listening on TCP/2049 or RPC/NFS-related ports.
• Review vendor kernel advisories for the exact fixed version for each deployed Linux distribution, appliance, or managed kernel stream.
• Restrict NFS access at network boundaries so only authorized clients can reach NFS/RPC services.
• If NFS is not required, disable nfs-server/nfsd and remove persistent exports.
• Monitor kernel logs for use-after-free, slab, KASAN, general protection fault, NULL pointer, or nfsd-related crash messages.
• Treat unexplained nfsd-related kernel panics after NFSv4 client activity as potentially security-relevant until patched and investigated.
• Because the issue is not currently KEV-listed and EPSS is low, balance urgency against exposure, but do not defer patching on externally reachable NFS servers.