CVE-2025-40273 Linux NFSd fix prevents copynotify list corruption

The Linux kernel has a newly published security advisory — CVE-2025-40273 — describing a flaw in the NFS server (nfsd) state-management code: a copynotify stateid can remain referenced when its parent open state is freed, leading to list corruption and a kernel OOPS when laundromat later processes the dangling copynotify entry. This fix was merged upstream to free the associated copynotify stateid from nfs4_free_ol_stateid and avoid later double-free or list-corruption faults.

Background / Overview​

NFSv4 introduces a collection of long-lived kernel objects — stateids, openowners, lockowners, delegations, and auxiliary notification entries — that track file opens, locks, copy/notify operations and client leases across the server and clients. Correct lifetime management of those objects is critical: misordering or missed frees can corrupt linked lists and produce kernel crashes or instability.
CVE-2025-40273 is rooted in this bookkeeping. Under a specific sequence — an OPEN that creates a parent open stateid, a subsequent COPY_NOTIFY that creates a copynotify stateid referencing the parent, and then a client reboot which causes the original client state to be expired — the parent open state can be released via release_openowner -> nfs4_free_ol_stateid, while the copynotify stateid created earlier remains attached. The laundromat worker, which later walks and frees expired copynotify state entries, can then attempt to free an entry whose parent was already removed, producing list corruption and a kernel OOPS. The NVD summary and public vulnerability records capture this sequence and the fix (free the copynotify stateid earlier). Why this matters in practice

• The defect affects the NFS server (nfsd), an infra-critical kernel subsystem used in many file servers and storage appliances.
• The primary operational impact is availability: kernel warnings, OOPS, and potential panics that crash or destabilize hosts running nfsd. Several public examples in the advisory trail demonstrate OOPS traces tied to list deletion failures inside _free_cpntf_state_locked / nfs4laundromat.
• The attack vector is local or client-driven: a misbehaving or buggy NFS client (or a client that reboots mid-sequence) can trigger the described interleaving. In multi-tenant or shared-storage environments, an untrusted tenant or a remote client with access to the NFS export can be enough to exercise this behavior.

Technical deep-dive​

The actors: stateids, copynotify entries, laundromat​

• Open/lock stateids: represent client opens and locks. They have lifetimes tied to the client lease and explicit CLOSE/FREE_STATEID operations.
• Copy-notify stateid: created by COPY_NOTIFY operations (pNFS / copy/copy-notify features) that track pending copy/notify completion semantics; these entries are linked off the parent open state.
• Laundromat thread: background nfsd workqueue that periodically scans for and reclaims expired stateids; it may free copynotify entries if they linger past lease expiry.

In the problematic scenario, a parent open state is freed before its associated copynotify entries are released. The nfs4_free_ol_stateid path historically assumed that copynotify stateids would be released elsewhere (on close or via the laundromat cleanup). That assumption is broken by the race: a client reboot creates a new client instance and forces the previous state to expire; the openowner is released and nfs4_free_ol_stateid runs while a copynotify entry still points at that openowner. When laundromat later processes and tries to free the copynotify entry it manipulates the same list that nfs4_free_ol_stateid left in an inconsistent state — a situation that can trigger __list_del_entry_valid_or_report and produce a kernel OOPS. The NVD and multiple public trackers reproduce the kernel trace pattern in their advisories.

The upstream fix (what code changes)​

The upstream maintenance commit changes nfs4_free_ol_stateid to explicitly free any copynotify stateids still attached to the open stateid at the time of release, instead of leaving them to laundromat alone. Concretely, the fix:

• Detects when an open owner being destroyed still has copynotify children attached.
• Synchronously frees those copynotify state objects while holding the appropriate locks and updating per-net nfsd lists (the same structures the laundromat would traverse).
• Removes the race window where laundromat could operate on a list that had an already-freed parent, preventing list-corruption and subsequent OOPS messages referencing __list_del_entry_valid_or_report and _free_cpntf_state_locked. Several upstream patches and mirrors show the commit(s) that implement this exact corrective action.

Observed symptom in kernel logs​

A publicly quoted oops string that accompanies the CVE is representative:

• WARNING/OOPS with a stack trace through __list_del_entry_valid_or_report and _free_cpntf_state_locked
• Context: nfs4_laundromat worker reclaiming expired state
• Outcome: kernel warnings, possible crash/reboot depending on how broadly the corruption hits kernel list structures. The advisory includes the OOPS snippet showing the exact list_del failure and call trace.

Affected versions and scope​

Public vulnerability feeds (NVD, OSV and mirrors) show that CVE-2025-40273 was published on 6 December 2025 and maps to upstream Linux kernel trees; stable backports were committed into relevant branches by kernel maintainers. Distribution-specific packages and vendor kernels will vary in which releases contain the fix (and some backports may be present in older stable kernels). Operators must therefore map their deployed kernel package versions to vendor security advisories. The canonical NVD/OSV entries list the vulnerability and reference upstream commits and/or stable patches; distribution security trackers (Debian, Ubuntu, SUSE, etc. are the authoritative place to find fixed package versions for managed systems. Caveat: kernel configuration matters. The NFS server code is compiled into kernels based on CONFIG*NFSD and related options. Two kernels built from the same upstream source can differ in surface area depending on build-time CONFIG** choices; a kernel that does not include nfsd or that disables the relevant features may be functionally not affected. Practical checks are therefore necessary on each host.

Operational impact and exploitability​

• Primary impact: availability — kernel oops/panic and potential host instability, not direct confidentiality/remote code execution in the general case.
• Attack vector: client-driven — a legitimate client (or attacker-controlled client) that performs OPEN + COPY_NOTIFY and then reboots / recreates a session can trigger the sequence. Multi-tenant environments where untrusted clients access exports increase the practical attack surface.
• Exploitability: This is a correctness/list-management bug that reliably produces OOPS traces in lab reproductions. There are no widespread reports of weaponized remote RCE exploits associated with this CVE at disclosure time in public trackers; the observed practical impact in field reports is OOPS / DoS. However, kernel-list corruption can sometimes be a stepping stone in complex exploit chains — maintain defenders should treat the defect seriously and remediate promptly.

Who should worry (priority model)​

• High priority (patch immediately)
• Production NFS servers (on-prem file servers, NAS appliances, storage hosts) that export shares and accept clients you do not fully trust.
• Multi-tenant storage providers, cloud block/file services, or environments where untrusted clients or tenants can issue NFS operations against the server.
• Medium priority (verify and plan)
• Hosts running kernels that include NFSD/NFSv4 but where NFS is not actively used; verify the kernel config and whether nfsd is loaded.
• Appliances or embedded devices that run vendor-supplied kernels — these require vendor-supplied backports or image updates.
• Low priority (monitor)
• Systems without nfsd support compiled in or those that do not export NFS services.

Detection, triage and hunting​

Immediate triage checklist (0–48 hours)

• Inventory: find hosts running nfsd or exporting NFSv4:
• systemctl status nfs-server
• lsmod | grep nfsd
• ps aux | grep nfsd
• uname -r ; zcat /proc/config.gz | grep -i nfs
  These quick checks help determine whether the subsystem is present and whether the host needs urgent action.
• Log search: look for kernel warnings like __list_del_entry_valid_or_report or OOPS traces referencing nfs4state.c, _free_cpntf_state_locked, nfs4_laundromat, or laundromat_main. These are the smoking-gun indicators the public advisories reproduce.
• Reproduce (safely, in test): if you need to validate whether a patched kernel resolves the issue, use a lab cluster and reproduce the reported sequence (OPEN → COPY_NOTIFY → client reboot → CREATE_SESSION) against an instrumented debug kernel.

Hunting rules (SIEM / EDR)

• Add kernel OOPS / WARN signature rules that match:
• __list_del_entry_valid_or_report
• _free_cpntf_state_locked
• nfs4_laundromat / laundromat_main
• Correlate OOPS events with NFS client activity (sudden reboots, session creations) to detect potential triggers.

Preserve artifacts: if you see evidence of the OOPS, collect dmesg, /var/log/kern.log, kdump coredump output and any logs from nfsd or containerized file server processes for later forensic analysis.

Remediation and mitigations​

Apply the upstream or vendor-provided kernel patches

• The authoritative remediation is the upstream kernel commit(s) that free copynotify stateids out of nfs4_free_ol_stateid. Confirm that your distribution’s kernel package changelog references the upstream commit or the CVE before you roll it out. Consume distro advisories (Debian/Ubuntu/SUSE/Red Hat/Oracle) and vendor kernels for the fixed package versions. Public trackers and OSV map the CVE to upstream commits and to patches that have been merged to the stable trees.

Short-term mitigations (when patching is delayed)

• Reduce exposure: restrict which clients can access NFS exports (network ACLs, export restrictions, firewall rules).
• Isolate untrusted workloads: move untrusted clients to a separate export with stricter access or disable pNFS / copy/notify features if your workload does not require them.
• Monitor OOPS: increase kernel-level telemetry and alerting so you can spot and respond to early signs of exploitation.
• Reboot windows and schedule patch windows carefully: kernel updates require reboots; plan staged rollouts to reduce blast radius.

Longer-term controls

• Ingest vendor VEX/CSAF outputs or distribution advisories into your SBOM and image management: this ensures future kernel-level CVE attestations are machine-actionable and automatable.
• Harden image provenance: rebuild and re-sign any custom images or appliances derived from vulnerable base kernels.

Concrete remediation steps (example)

• Identify affected hosts:
• uname -r
• zcat /proc/config.gz | grep -i nfs
• lsmod | grep nfsd
• Consult your distro security tracker for the exact fixed kernel package for your release.
• Apply the vendor kernel package that includes the upstream fix and reboot hosts in a controlled, staged manner.
• Validate post-patch by confirming updated kernel version and absence of OOPS traces.

Vendor and public response​

Upstream kernel maintainers accepted stable patches that implement the safety change described above, and the CVE was assigned and published (NVD / OSV / public trackers updated with the description and the commit references). Independent advisories and mirrors (CVE Details, cvefeed, security vulnerability aggregators) reflect the same technical summary and reproduce the OOPS traces that motivated the patch. Operators should treat these upstream commits as the canonical fix and rely on distribution channels for backports into packaged kernels. A practical note about Microsoft / vendor attestations

• Large vendors sometimes publish product-scoped VEX/CSAF attestations when they have completed per-product inventories (for example, Microsoft did this previously for Azure Linux in other NFSD-related advisories). These attestations can accelerate triage for the attested image families, but they are product-scoped: absence of an attestation does not mean an artifact is safe — operators must still verify per-image kernels and configurations. This is an important operational nuance when sweeping large, heterogeneous estates for kernel CVEs.

Critical analysis — strengths and residual risks​

Strengths of the upstream response

• The fix is surgical and targets the precise lifetime-management omission; such small, well-scoped patches are easier to backport and less likely to introduce regressions.
• Public trackers and OSV quickly mapped the CVE to upstream commits and to distribution advisories, enabling operators to locate fixed packages.

Risks and blind spots

• Distribution and vendor lag: embedded, OEM, or vendor-kernel builds may not be patched promptly, leaving a long tail of exposed devices and appliances.
• Complexity of kernel configuration: kernels without nfsd or with nfsd compiled out are unaffected, but many cloud images, appliances, and market images differ in configuration and must be checked individually.
• Attack surface in multi-tenant environments: environments that accept NFS requests from many clients (public-facing exports, multi-tenant storage) have a higher practical risk profile because client-driven sequences are sufficient to trigger the fault.
• Possibility of chained exploitation: while the immediate impact is DoS/OOPS, list corruption and kernel memory corruption are potent primitives that can — in rare and sophisticated circumstances — be leveraged as part of an escalation chain. Treat such possibilities as low-probability but high-impact and remediate accordingly.

Unverifiable or evolving items

• At disclosure there are no widely reported, reliable public exploit campaigns weaponizing this specific CVE for privilege escalation; publicly available advisories emphasize availability impact. Operators should still assume exploitation is possible and patch proactively. If future new exploit reports appear, update triage priorities accordingly.

---

Recommended checklist (operational playbook)​

• Inventory (first 24 hours)
• Identify all hosts running nfsd or exporting NFSv4: uname -r; zcat /proc/config.gz | grep -i nfs; lsmod | grep nfsd.
• Flag multi-tenant exports, cloud images, and Marketplace appliances for high priority.
• Map to vendor packages (day 1–3)
• Consult your distribution’s security advisory for the CVE mapping and the fixed kernel package version.
• For vendor appliances, contact the vendor for a fixed image or patch.
• Patch and validate (day 1–7)
• Apply vendor-supplied kernel packages that contain the upstream fix.
• Reboot hosts in staged waves; validate absence of OOPS and re-check nfsd functionality.
• Short-term mitigations (if you cannot patch immediately)
• Restrict exported NFS access to trusted networks.
• Disable pNFS / copy-notify features if not required by your workload.
• Monitor kernel logs for WARN/OOPS signatures and enforce alerting.
• Long-term (2–8 weeks)
• Automate SBOM ingestion and VEX/CSAF consumption so vendor attestations are machine-actionable.
• Rebuild and re-publish any custom images that used vulnerable kernels.
• Harden host and image lifecycle to reduce the long tail of old snapshots or cached images.

Conclusion​

CVE-2025-40273 is a kernel-level NFSD state-management bug that exposes NFS servers to a reliable availability failure: list corruption and kernel OOPS when copynotify stateids remain attached after the parent open stateid is freed. The upstream fix eliminates the race by freeing associated copynotify stateids in nfs4_free_ol_stateid, and distributions will be publishing backported packages. The immediate operational priority is clear: identify hosts that run nfsd, apply vendor/kernel updates that include the upstream commit, and apply compensating access restrictions for unpatched hosts. While the vulnerability’s impact is primarily availability-focused rather than a confirmed remote code-execution vector, kernel-level list corruption is serious and merits rapid remediation and careful validation.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center