CVE-2026-22980 Linux NFSd End Grace Race Fixed: Prevent Use After Free

The Linux kernel received a targeted fix for a subtle but potentially disruptive race condition in the NFS daemon (nfsd) that could lead to memory being accessed after it was freed. Tracked as CVE-2026-22980, the issue centers on handling of the NFSv4 grace period end — specifically the v4_end_grace write path — and the way that scheduling and shutdown races could produce a use‑after‑free in internal reclaim data structures. The fix introduces carefully scoped net‑namespace flags and spinlock‑protected checks to prevent the laundromat (the background work used to finish client state processing) from being restarted after shutdown has already waited for it. For administrators and engineers who operate NFS servers or manage Linux hosts in mixed Windows/Linux environments, this is a reliability and availability issue that deserves timely attention.

Background​

NFSv4 introduces a grace period during server restarts to allow clients to reclaim locks and state. The server exposes administrative controls (including a v4_end_grace entry) so that operators or control paths can signal the end of that special handling period. Under normal conditions, internal synchronization and lifecycle rules prevent races between client requests, background worker scheduling, and server shutdown.
The vulnerability arises when writes to the v4_end_grace control path race with server shutdown and with client tracking code paths that may cause re-entrancy into the same control path. The interaction between different locks and workqueue scheduling made it impossible to simply hold the usual nfsd_mutex across the nfsd4_end_grace() call without risking deadlock. As a consequence, a timing window could allow code to schedule background work (the laundromat) after shutdown already completed waiting on that work — leading to use‑after‑free on structures such as reclaim_str_hashtbl.
This class of bug — a race producing use‑after‑free inside the kernel — commonly results in instability (kernel oops/panic), denial of service (system crash), and, in certain circumstances, may be a stepping stone toward privilege escalation or arbitrary code execution. The patch applied in upstream kernel code introduces a per‑net (per‑network namespace) flag and a second flag to mark a forced end to grace, and uses nn->client_lock to make writes to v4_end_grace safe with respect to shutdown sequencing.

---

Overview of the fix and why it matters​

• The fix adds a client_tracking_active boolean to the nfsd per‑net structure. This flag is set only when it is safe to perform client tracking operations that may cause upcalls into client tracking subsystems.
• A complementary grace_end_forced flag is introduced to record when a write to v4_end_grace has occurred. When this flag is set and client_tracking_active is true, the laundromat worker may be scheduled to finish reclamation.
• Writes to v4_end_grace are gated by the spinlock that protects nn->client_lock, ensuring that scheduling will not restart the laundromat after the shutdown has already waited on it.
• The change avoids holding nfsd_mutex across nfsd4_end_grace() because client tracking initialization may involve upcalls that themselves can write to v4_end_grace; holding the mutex there could create deadlock cycles.

Why this matters: without these safeguards, a well‑timed or concurrent administrative write or client activity could cause background work to reference memory that the shutdown path already freed. That pattern explains the observed vulnerability: a use‑after‑free triggered by concurrent writes and shutdown activity in NFSd, and manifests most directly as crashes or corruption in reclaim structures.

---

Technical analysis​

Where the race happens​

• The vulnerable code path involves the nfsd4_end_grace() function invoked in multiple contexts: synchronous administrative writes and asynchronous laundromat workqueue execution.
• When server shutdown is in progress, code waits for outstanding work items to complete. However, writes to v4_end_grace could previously schedule laundromat work without adequate synchronization with shutdown sequencing.
• Holding nfsd_mutex across the nfsd4_end_grace() call is undesirable because client tracking calls triggered during initialization may block waiting for an upcall to a helper (nfsdcltrack). That helper could itself attempt to write v4_end_grace, leading to deadlock if the mutex were held.

The root cause​

• The root is a timing / ordering mismatch between:
• shutdown waiting for workqueue items to finish; and
• external writes that could re-schedule the same workqueue item after shutdown believes it is done.
• Because the laundromat work can be scheduled from multiple contexts, one must ensure a global “it’s safe to schedule” condition that is visible to both scheduler and shutdown paths.
• The fix adds such a condition (client_tracking_active) and a forced end marker (grace_end_forced) to coordinate actuations safely under a spinlock.

What the patch does (high level)​

• Introduces new per‑net state to nfsd.
• Ensures v4_end_grace writes only schedule laundromat work while client_tracking_active is set and while holding the nn->client_lock spinlock.
• Uses grace_end_forced to bypass other checks when the admin explicitly forces end-of-grace, preventing missed scheduling when appropriate but without re‑starting work after shutdown synchronization completed.
• This transforms an unsafe race into a locked, ordered transition so that the laundromat will never be restarted after shutdown has already waited on it.

---

Affected systems and likely exposure​

• The vulnerability is in the NFS daemon code inside the Linux kernel — the issue is a kernel‑space use‑after‑free triggered by certain NFSv4 administrative/control flows.
• This is a local attack vector issue: the ability to write to v4_end_grace or otherwise trigger client tracking paths is generally local or administrative activity rather than unauthenticated network access. In practice, local users with the appropriate privileges, privileged daemons, or incorrectly exposed administrative interfaces could trigger the condition.
• Distributions and kernels that incorporated the upstream patch are fixed; others remain vulnerable until they apply the backport or upgrade to a kernel that includes the fix.
• The practical impact is highest on systems that run nfsd (NFS server) — file servers, NAS devices using mainline kernel code, or virtual appliances that expose NFSv4 server functionality.

Note: product and distribution patch timelines vary. Some vendors classify the impact as moderate (availability impact) while others score the issue higher depending on potential for memory corruption and kernel instability. Administrators should consult their vendor advisories for distribution‑specific fixed package versions and CVSS scoring.

---

Risk assessment: what can go wrong?​

• Primary impact: Availability. The most immediate and likely outcome of triggering the race is a kernel crash (oops) or system instability caused by use‑after‑free. This results in service interruption — particularly bad for storage servers and clustered filesystems using NFS.
• Secondary risk: Integrity / Confidentiality. Use‑after‑free bugs can sometimes be escalated into arbitrary code execution or privilege escalation, but doing so in a kernel environment typically requires a combination of additional primitive weaknesses. There is no public evidence at the time of disclosure that CVE‑2026‑22980 has been used in the wild to achieve code execution or data exfiltration. Treat such escalation as a plausible but unproven risk.
• Attack complexity: this is a race condition that may require local access or privileged operations, and precise timing to trigger. That raises the bar compared to simple remote exploit paths, but does not eliminate the risk to multi‑tenant or shared systems where local privilege separation is imperfect.
• Exposure scenarios:
• Multi‑tenant virtualization hosts exposing NFS server to guests or containers that can influence v4_end_grace.
• Admin scripts and orchestration tools that write v4_end_grace concurrently with shutdown or state transitions.
• Misconfigured management interfaces that expose administrative controls to untrusted actors.

Caution: statements about exploitability or observed active exploitation should be treated carefully; if an organization requires an absolute proof of exploit, perform controlled testing in an isolated lab on vulnerable kernels or consult vendor security advisories.

---

Mitigation and remediation​

The only reliable remediation is to update the kernel to a version that includes the upstream fix or to apply a vendor backport. Because this is a kernel use‑after‑free, the fix is not simply a userland patch or configuration switch in most cases.
Recommended immediate actions:

• Identify affected hosts:
• Inventory systems that run nfsd (NFS server), including dedicated file servers, SAN/NAS appliances using upstream kernels, virtual appliances, and containers with host-capable NFS server features.
• Check kernel version and distribution package versions against vendor advisories and fixed package versions.
• Apply vendor security updates:
• Prioritize distribution kernel updates as provided by your vendor or distribution security team.
• Where distributions have released fixed kernel packages, plan for testing and rollout. Many vendor advisories will list fixed package versions; use those as the authoritative target.
• If using long‑term support kernels, confirm whether vendor backports are available and apply them.
• Reduce attack surface until patched:
• If NFS server functionality is not required, stop and disable the NFS server daemon and remove the module(s) where possible: stop nfsd services and unexport shares.
• If NFS server is required but administrators can temporarily isolate it, restrict local administrator access and avoid triggering v4_end_grace writes during planned shutdown/activity windows.
• Enforce tight host access control: ensure only trusted, authenticated administrators may perform actions that write to control entries like v4_end_grace.
• Avoid risky operational sequences during mitigation window:
• When planning NFS server restarts or reconfiguration, avoid concurrent scripts that might write v4_end_grace while shutdown is in progress.
• Schedule maintenance windows and ensure one controlled sequence for ending grace and shutting down to reduce race likelihood.
• Monitor and log:
• Watch for kernel oopses, crashed systems, or unexplained NFS server instability in the days following discovery. Increase scrutiny of syslog, kernel logs, and crash dumps.
• Enable and capture core dumps or kdump data for any crashes to assist with forensic analysis.
• Test before wide rollout:
• Kernel updates require reboots. Test updated kernels in staging environments that mirror production workloads, paying particular attention to NFS server behavior under load and during shutdown sequences.

---

Hardening checklist (practical, prioritized)​

• Immediate (within 24–72 hours)
• Inventory NFS servers and note which hosts run upstream or vendor kernels without the fix.
• If possible, stop the NFS server service on non‑production hosts until patched.
• Restrict local admin access and management interfaces to only necessary personnel.
• Short term (1–2 weeks)
• Deploy vendor-provided kernel updates that contain the fix or backport.
• Reboot hosts in a staged manner after testing to bring patched kernels online.
• Update configuration and orchestration scripts to serialize NFS admin actions during shutdown/restart windows.
• Medium term (1–3 months)
• Revise operational playbooks to avoid concurrent v4_end_grace writes and avoid automations that race with shutdown.
• Increase automated monitoring for kernel oops, crash frequency, and abnormal NFSd logs.
• Run fuzzing or stress tests in a lab environment that simulate concurrent client tracking, laundromat scheduling, and shutdown to validate the fix in your environment.

---

Recommendations for Windows administrators and mixed environments​

Even though this vulnerability affects Linux kernel code, Windows administrators often interact with Linux NFS servers in mixed environments (file shares, build servers, virtualization, containers, cloud storage gateways). Here’s what Windows-focused IT teams should do:

• Identify NFS endpoints that Windows hosts mount or rely on for backup, file transfers, or virtualization storage. Prioritize those hosts for patching.
• Coordinate patching windows across teams: Linux kernel updates require reboots and will affect services consumed by Windows infrastructure.
• If you run WSL (Windows Subsystem for Linux) or virtual machines that host NFS services for Windows tooling, ensure those Linux kernels are updated as appropriate.
• Maintain clear change windows for cross‑platform services; avoid simultaneous shutdowns and administrative commands that could create races.
• For enterprises using NAS appliances, verify with your storage vendor whether they are affected and request timeline for firmware/OS updates; apply vendor guidance promptly.

---

How to validate whether a host is patched​

• Confirm the kernel version and compare to vendor advisory fixed versions or to upstream commit ranges. Vendors maintain lists of fixed package versions; match your host kernel package to the fixed release.
• Observe that after applying a patch, normal NFSv4 administrative writes and shutdown sequences do not produce kernel oopses under stress tests that previously reproduced the issue.
• If you maintain additional mitigations (e.g., firewalling administrative management interfaces), verify that they remain effective post‑update.

Caveat: version numbers and vendor package identifiers vary; always consult your distribution or vendor security advisory for the authoritative fixed package identifier rather than relying on generic kernel version heuristics.

---

What defenders should avoid assuming​

• Do not assume this is a remotely exploitable remote code execution vulnerability; primary reports indicate a local race that leads to use‑after‑free and availability impact. Treat claims of remote exploitability with skepticism unless confirmed by reproducible public proof or vendor advisory.
• Do not assume that simply stopping nfsd is a complete mitigation in every environment; some embedded or appliance kernels may embed NFS code differently.
• Do not assume that older kernels are safe; many long‑term support kernels may require vendor backports and have different patch timelines.

If you need to establish proof of exploitability or want to harden further, consider controlled technical validation in a lab that replicates your production configuration.

---

Final assessment and operational guidance​

CVE‑2026‑22980 is a targeted, non‑trivial kernel race that affects the NFS daemon’s end‑of‑grace handling and can result in memory being accessed after it is freed. The upstream remedy is surgical: it introduces per‑net state and spinlock‑protected scheduling rules that avoid restarting background work after the shutdown path has already synchronized. For most organizations the correct operational response is straightforward: treat this as a high‑priority kernel stability/security update for any host running NFS server functionality, apply vendor updates or upstream fixes as soon as practical, and harden operational procedures to avoid accidental administrative races while unpatched.
Prioritize patching of shared storage servers, virtualization hosts that might expose NFS services, and appliances that rely on mainline kernels. For the interim, reduce exposure by disabling unnecessary NFS services, restricting administrative access, and sequencing maintenance steps to avoid concurrent v4_end_grace writes and shutdown operations.
This is the sort of subtle kernel bug that demonstrates how complex interactions between synchronous control paths, asynchronous background jobs, and lifecycle/shutdown sequencing can create real-world risks. The upstream fix respects those constraints: it provides the minimal, lock‑correct semantics required to safely coordinate laundromat scheduling and shutdown. Administrators should treat this as an availability risk with potential for greater impact if chained with other vulnerabilities — and should remediate accordingly.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center