On December 6, 2025, a newly assigned vulnerability, CVE-2025-40273, shed light on a kernel-level flaw in Linux’s NFS server that can silently corrupt internal state lists and cause the server to crash. The bug churns below the surface in the way NFSv4 manages copy-notify operations, and its trigger sequence—an OPEN, a COPY_NOTIFY, and a client reboot—is just plausible enough to pose a real operational risk for any host exporting NFS shares. An upstream fix has already been merged, and distribution kernels are following suit with backports. If you run an NFS server, you need to check your kernel version now.

What Actually Broke

The vulnerability lives in the NFS server’s state tracking for copy/notify operations. NFSv4 uses long-lived kernel objects—open stateids, lock stateids, delegations, and a variety of auxiliary entries—to keep track of file access across reboots and network blips. One such auxiliary is the copynotify stateid, created when a client issues a COPY_NOTIFY operation (part of the pNFS or server-side copy feature). These entries are linked off a parent open stateid, which represents an open file.

Under normal conditions, the kernel’s internal “laundromat” thread periodically sweeps through and reclaims expired stateids, including orphaned copynotify entries. But a subtle race was uncovered: when a client abruptly reboots—or its lease expires in a certain way—the server can destroy the parent open stateid via nfs4_free_ol_stateid before the laundromat has a chance to free the associated copynotify stateid. The parent disappears, but the copynotify entry still points at it.

When the laundromat later encounters that dangling entry and tries to unlink it from the list, it operates on memory that has already been freed and possibly reused. The result is a corrupted linked list, which the kernel catches with a verbose warning: stack traces through __list_del_entry_valid_or_report and _free_cpntf_state_locked are the telltale sign. In severe cases, this list corruption can cascade into a full kernel OOPS or panic, taking the NFS service—and possibly the entire machine—offline.

The fix, accepted upstream, modifies nfs4_free_ol_stateid to explicitly free any copynotify stateids that are still attached to the open stateid at the moment it is destroyed. This eliminates the window where laundromat could ever see a dangling pointer. The patch is small and surgical, touching only the state‑management code in fs/nfsd/nfs4state.c.

What This Means for You

Not every Linux user will be impacted. The bug only affects systems where the kernel’s NFS server (nfsd) is active and exporting NFSv4 shares to clients that can perform COPY_NOTIFY operations. Still, that covers a wide variety of setups.

If you’re a home user running a personal file server (TrueNAS, Unraid, or a hand-rolled Linux box exporting NFS), the risk is lower but not zero. If your clients are all friendly devices on your LAN, an accidental trigger would look like a client rebooting while a file copy was in progress—unlikely but possible. A kernel OOPS would crash your server, requiring a reboot and possibly leaving file systems inconsistent.

System administrators in enterprises and cloud providers should pay close attention. Multi‑tenant environments—where many clients, potentially untrusted, mount the same NFS export—face an elevated threat. A misbehaving client, or one that simply reboots mid‑operation, could trigger the race and crash the server. In storage clusters or NAS appliances that serve hundreds of clients, a single unpatched node could cause a cascading availability problem.

Developers and kernel maintainers who build custom kernels should ensure the patch is applied. The fix is already in Linus Torvalds’ tree and has been merged into the stable branches (likely 5.15, 6.1, 6.6, and 6.12 series, given the December timing). If you track a long‑term kernel, verify that your local tree includes the commit.

There is no evidence that the bug can be directly exploited for remote code execution. Public advisories categorize the impact as availability‑only: a denial of service. However, list corruption in the kernel is never benign—it can open the door to more sophisticated attacks if an adversary can control the corrupted data. Prudent admins will treat this as a high‑priority patch.

How We Got Here

The NFSv4 state‑management machinery is notoriously complex. The nfs4state.c file alone runs over 7,000 lines, and the interactions between stateids, clients, sessions, and the laundromat thread have been refined over many kernel releases. The specific sequence that triggers CVE‑2025‑40273 likely lurked undetected for years; it requires a COPY_NOTIFY operation (less common than basic opens and locks) followed by a client state expiration that tears down the openowner in a specific order.

Public vulnerability records show that the issue was first disclosed via the National Vulnerability Database on December 6, 2025, and the upstream commit was authored by a kernel developer who pinned down the race after reproducing the OOPS in a test environment. The fix has since been propagated to stable kernels and through distribution security trackers: Debian, Ubuntu, SUSE, Red Hat, and Oracle Linux all maintain advisories mapping the CVE to their specific package versions.

Microsoft’s Security Response Center also lists the CVE, given that Azure Linux (Mariner) and other Microsoft‑maintained kernels are derived from upstream Linux. The MSRC advisory is minimal but confirms the vulnerability and points to upstream fix resources.

What to Do Now

1. Inventory Your NFS Servers

Run these commands on any Linux host that might be exporting NFS:

systemctl status nfs-server   # Is the NFS server service running?
lsmod | grep nfsd             # Is the nfsd kernel module loaded?
ps aux | grep nfsd            # Are there nfsd threads active?
uname -r                      # What kernel version are you on?
zcat /proc/config.gz | grep -i nfsd  # Is CONFIG_NFSD enabled?

If nfsd shows up as loaded and you see active exports, you’re potentially affected. Note the kernel version—you’ll need it to check for a fixed package.

2. Check Your Distribution’s Advisory

Each Linux distribution publishes security announcements that map a CVE to a minimal fixed kernel package version. For example, on Ubuntu you might run:

apt list --installed | grep linux-image

Then compare against the Ubuntu Security Notice for CVE‑2025‑40273. On Red Hat or SUSE, use yum or zypper similarly. The key is to ensure your kernel package incorporates the upstream commit that frees copynotify stateids in nfs4_free_ol_stateid. If your distribution has not yet released a patch, apply mitigations.

3. Apply the Patch or Mitigate

Patch – The ideal path. Schedule a maintenance window, install the updated kernel package, and reboot each server one at a time. Staging the rollout reduces the blast radius if something goes wrong.

Mitigate – If you can’t patch immediately:
- Restrict NFS exports to trusted client IP ranges using /etc/exports or firewall rules.
- Disable pNFS / copy‑notify features if your workload permits. (You can set the module parameter nfsd_disable_pnfs=1 on many kernels, but verify in your distribution’s documentation.)
- Monitor kernel logs aggressively for __list_del_entry_valid_or_report or _free_cpntf_state_locked warnings. Set up alerts so you catch any OOPS early.

4. Validate the Fix

After rebooting into the patched kernel, confirm the new version (uname -r) and check that the OOPS signatures have not reappeared. If you’ve been seeing sporadic crashes, now is the time to ensure that your NFS clients’ normal workload no longer triggers the bug.

Outlook

Expect all major Linux distributors to ship patched kernels within their usual security update cadences—often within days for high‑impact bugs. Large cloud providers and appliance vendors (including those using Microsoft Azure Linux) will likely publish VEX/CSAF attestations that simplify compliance scanning for large fleets. Microsoft has done this for previous NFSD‑related advisories, and the same is likely here.

The one wild card is embedded and OEM devices: NAS appliances, routers, and IoT gear that silently include NFSD. These devices often lag far behind on kernel updates. If you manage such devices, contact the vendor for a firmware update, and isolate them from untrusted networks in the meantime.

In the broader security landscape, CVE‑2025‑40273 is a reminder that even mature kernel subsystems can harbor subtle race conditions. The availability risk is real, the fix is simple, and every NFS admin should act now—before an unexpected crash reminds you the hard way.