CVE-2026-53244

What it actually does

This Linux kernel flaw affects the NFS server code path for NFSv4 file creation. When NFSD exports a filesystem that implements the atomic_create operation, an error returned during file creation can cause nfsd4_create_file() to pass an error pointer into end_creating() instead of a valid dentry. Because end_creating() needs the dentry to unlock the parent directory, the parent may remain locked. The practical technical result is a kernel-level denial of service affecting the exported filesystem path: NFSD worker threads and other processes accessing the locked directory can hang, block in uninterruptible sleep, or exhaust service capacity until recovery, often requiring a reboot if the lock cannot be cleared safely.

Why it matters to the business

Successful exploitation can make NFS exports partially or fully unavailable, disrupting applications, users, batch jobs, virtualization platforms, container workloads, or shared storage workflows that depend on Linux NFSD. Because the bug can leave kernel locks stuck rather than simply crashing a single process, service recovery may require disruptive intervention such as restarting NFSD or rebooting the server. The vulnerability is not currently listed in CISA KEV, is not known to be ransomware-associated, and has a low EPSS score of 0.00344, indicating low observed exploitation likelihood; however, internet- or broadly network-accessible NFS services should still be prioritized because availability impact can be high.

How an attack unfolds

An attacker first needs network reachability to an affected Linux NFS server and access to an exported NFSv4 share where file creation is permitted or otherwise reaches the create path. The attacker then issues NFSv4 create operations against an exported filesystem that uses the kernel atomic_create method. If the create operation causes atomic_create to return an error, the vulnerable kernel path can mishandle the dentry reference and pass an error pointer to the cleanup/unlock routine. Instead of unlocking the parent directory, the parent remains locked. Subsequent NFSD requests or local filesystem operations touching that directory may block, causing NFS worker thread exhaustion, hung tasks, degraded application behavior, or loss of access to the export. Exploit maturity is currently assessed as none, so defenders should expect exploitation, if attempted, to resemble abnormal or repeated NFSv4 create failures rather than a widely available public exploit chain.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the NFSD dentry_create()/nfsd4_create_file() locking behavior. Because no fixed product versions were provided, use the relevant Linux distribution or appliance vendor advisory to identify the first fixed kernel package or backported patch level. Reboot into the fixed kernel unless the vendor provides a verified live patch. As interim risk reduction, restrict NFS exposure to trusted networks, enforce host firewall rules and export ACLs, remove unnecessary write/create permissions, make exports read-only where operationally possible, and disable or limit NFSD on systems that do not require it. If the issue is triggered and directories or nfsd threads remain hung, restarting NFSD may not fully clear kernel lock state; plan for a controlled reboot if service cannot be safely restored.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, contains the vendor backport or upstream fix. Validate with uname -a, package manager metadata, and the vendor advisory for this CVE or associated kernel commit. Confirm NFSD has been restarted or the host rebooted into the fixed kernel. Review NFS exports with exportfs -v and verify unnecessary writable exports have been removed or restricted. In non-production only, exercise NFSv4 create-error behavior against representative exports and confirm NFSD remains responsive, no parent directories remain locked, and no nfsd tasks enter prolonged uninterruptible sleep. Operational validation should include checking that NFS clients can create, fail, retry, and delete files normally after patching.

Typical attack path

1. Identify a reachable Linux server exposing NFS/NFSD, especially NFSv4.
2. Obtain or use existing access to an exported share where file creation requests can be attempted.
3. Target a filesystem/export combination that uses the kernel atomic_create operation.
4. Send create requests that trigger an error return from atomic_create.
5. Cause the vulnerable NFSD code path to fail to unlock the parent directory.
6. Repeat or sustain activity until NFSD workers, clients, or local processes block on the locked directory.
7. Leverage the resulting service degradation as a denial-of-service condition against workloads dependent on the export.

How to detect it

Look for evidence of abnormal NFSv4 create activity followed by NFSD or filesystem hangs. Useful sources include kernel logs, system journal, syslog, auditd file creation records if enabled, NFS server telemetry, firewall/VPC flow logs, and storage/application monitoring. Investigate repeated create failures from the same client IPs, sudden increases in NFSD thread usage, clients reporting stalled NFS operations, and kernel hung-task messages naming nfsd or processes blocked on exported directories. Correlate timestamps between NFS client errors, server-side kernel messages, and network traffic to TCP/2049. Because this flaw primarily causes a denial-of-service condition and does not inherently write a unique file or spawn a userland process, detection relies on behavioral indicators rather than a stable malware-like artifact.

• INFO: task nfsd
• nfsd: blocked for more than
• blocked for more than 120 seconds
• hung_task_timeout_secs
• task nfsd
• nfsd4_create_file
• end_creating
• atomic_create
• NFSv4 CREATE
• nfsd: last server has exited
• rpc.nfsd
• /proc/fs/nfsd
• tcp/2049
• port 2049

What your security team should do

• Inventory Linux systems running NFSD and prioritize those exposing writable NFSv4 exports, especially across broad internal networks or untrusted segments.
• Patch affected kernels using vendor-provided fixed packages or live patches, then reboot or otherwise ensure the fixed kernel is active.
• Restrict NFS access with firewalls, security groups, TCP wrappers where applicable, export ACLs, and network segmentation.
• Review exports and convert writable shares to read-only where write access is not required.
• Monitor NFSD availability, nfsd worker saturation, hung kernel tasks, and repeated NFSv4 CREATE errors.
• Search logs for signs of prior denial-of-service attempts, including repeated file creation failures followed by hung nfsd tasks or blocked filesystem operations.
• Prepare an operational recovery procedure for affected NFS servers, including client impact assessment and controlled reboot steps if locks cannot be cleared.