CVE-2026-53026

What it actually does

This is a race condition in the Linux kernel NFS server (NFSD) NFSv4 delegation/access tracking path. Under concurrent access, nfsd4_add_rdaccess_to_wrdeleg() can incorrectly increment the nfs4_file access count when read access has already been established by another thread. The resulting reference-count imbalance can prevent the associated nfsd_file object from being freed. The observable impact is kernel resource leakage and, when the NFS server service is stopped or NFSD state is torn down, a kernel BUG triggered during kmem_cache_destroy()/__kmem_cache_shutdown because nfsd_file objects remain allocated.

Why it matters to the business

Organizations running Linux NFS servers may experience NFS service instability, failed or disruptive service shutdowns, kernel BUG events, and potential host reboots or maintenance delays. The practical risk is operational disruption to file-sharing workloads, CI/build systems, home directories, virtualization storage, or application data paths that depend on NFS. Current exploitation likelihood appears low: EPSS is 0.00426, it is not listed in CISA KEV, there is no known ransomware association, and no public exploit maturity is indicated. However, because NFS servers are often shared infrastructure, even a reliability-focused kernel bug can have broad operational impact if triggered repeatedly by heavy or concurrent NFSv4 workloads.

How an attack unfolds

An attacker, or any user able to generate NFSv4 client activity against an affected Linux NFS server, would need to create concurrent file access patterns that exercise the NFSD delegation/access transition handled by nfsd4_add_rdaccess_to_wrdeleg(). If the race is won, the kernel records an extra nfs4_file access reference. That stale count prevents the corresponding nfsd_file object from being released. The issue may not immediately produce visible effects during normal file operations; it is most apparent during NFS server shutdown, module/service teardown, or cleanup, when the kernel detects remaining nfsd_file objects and triggers a BUG in slab cache shutdown. This is best characterized as a denial-of-service or reliability issue rather than a direct data theft or privilege escalation vulnerability based on the provided information.

How to fix it

Update the Linux kernel to a vendor release that includes the NFSD fix for the nfsd4_add_rdaccess_to_wrdeleg() access-count race. Because affected products and exact fixed versions were not provided, use the distribution or kernel vendor advisory for CVE-2026-53026 to identify the corrected kernel package for each platform. After installing the fixed kernel, reboot into the updated kernel; simply restarting nfs-server is typically insufficient for kernel fixes. If immediate patching is not possible, reduce exposure by limiting NFS access to trusted clients only, enforcing firewall controls around NFS-related services, disabling unnecessary NFS exports, avoiding untrusted multi-tenant NFS access, and scheduling NFS service restarts during controlled maintenance windows. Consider reducing high-concurrency NFSv4 workloads or disabling features that increase delegation-heavy behavior only if vendor guidance supports doing so and operational impact is acceptable.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a vendor kernel version documented as fixed for this CVE, not merely that the package is installed. Validate with uname -a, package manager output, and vendor advisory mapping. Confirm the NFS server has been rebooted into the updated kernel. Where feasible in a non-production test environment, run a concurrent NFSv4 workload similar to CI/build or filesystem stress tests, then restart the NFS service and review dmesg/journal logs for absence of NFSD-related BUG messages, kmem_cache_destroy() failures, __kmem_cache_shutdown warnings, or lingering nfsd_file object messages. Also verify that NFS exports remain reachable and that service stop/start operations complete cleanly.

Typical attack path

1. Gain the ability to access an exported NFSv4 share or otherwise generate NFSv4 client operations against the affected Linux NFS server.
2. Create high-concurrency file activity against the NFS export, especially workloads involving repeated opens, reads, writes, and delegation/access state transitions.
3. Trigger the race in NFSD where read access is added while another thread has already established the read file descriptor/access state.
4. Cause an extra nfs4_file access reference count to remain, preventing the associated nfsd_file object from being freed.
5. Wait for, induce, or coincide with NFS server shutdown/restart or NFSD teardown.
6. The kernel detects leftover nfsd_file objects during cache destruction and triggers a BUG, potentially disrupting the NFS service or host.

How to detect it

Detection is primarily log- and symptom-based because the issue is a kernel race condition and does not provide a unique network payload or persistent artifact. Review kernel logs, system journals, crash dumps, and NFS service logs for BUG or warning messages involving NFSD cleanup, nfsd_file objects, kmem_cache_destroy(), or __kmem_cache_shutdown. Focus on time windows around NFS service stop/start, host shutdown, kernel oops/panic events, or unexplained NFS outages. Correlate these events with NFS client activity, especially high-concurrency workloads, build/test suites, repeated open/read/write operations, or many simultaneous clients. If crash dumps are available, inspect stack traces for nfsd4_add_rdaccess_to_wrdeleg, __nfs4_file_get_access, NFSD delegation/access management, kmem_cache_destroy, and nfsd_file slab/cache shutdown paths. Because legitimate workloads can trigger the bug, identify whether a small set of clients generated unusually heavy NFSv4 activity immediately before the BUG. Network telemetry may show bursts of NFSv4 traffic to TCP/2049, but there are no specific packet signatures derivable from the provided vulnerability details.

• nfsd4_add_rdaccess_to_wrdeleg
• __nfs4_file_get_access
• kmem_cache_destroy
• __kmem_cache_shutdown
• nfsd_file object remaining
• nfsd_file
• NFSD: fix nfs4_file access extra count
• BUG: kernel BUG
• kernel BUG at
• nfs4_file
• fi_access
• nfs-server
• nfsd

What your security team should do

• Prioritize patching Linux systems that run NFS server/NFSD, especially shared storage, build, CI, virtualization, and user home-directory servers.
• Inventory internet-exposed or broadly reachable NFS services and restrict access to trusted networks and clients; NFS should not be exposed to untrusted networks.
• Coordinate with infrastructure teams to ensure systems are rebooted into the fixed kernel after patch installation.
• Monitor kernel logs for NFSD, kmem_cache_destroy(), __kmem_cache_shutdown, and nfsd_file BUG messages, particularly after NFS service restarts or maintenance windows.
• Treat repeated NFSD kernel BUG events or unexplained NFS service disruptions as potential exploitation or stress-triggering until logs and workload sources are reviewed.
• If patching must be delayed, reduce NFS export scope, apply host/network firewall rules, and limit high-concurrency untrusted NFS workloads.
• Track vendor advisories because no exact affected product list or fixed package versions were provided in the input.