ZeroHour

CVE-2026-89684

large

Race condition in Linux kernel nfsd lets NFSv4.2 clients crash NFS servers

CVSS 3.1
7.5 high
EPSS
Published
()
Modified
AI analysis

A race condition in the Linux kernel's NFS server daemon (nfsd) allows a remote denial of service by crashing the server kernel. The flaw is in the NFSv4.2 server-to-server copy code: nfs4_alloc_init_cpntf_state() published a new copy-notify (cpntf) entry into the s2s_cp_stateids IDR before linking it onto the source state's sc_cp_list, leaving a window where the entry is findable by ID but has an uninitialized (zeroed) list head. Any NFSv4.2 client that issues a racing OFFLOAD_CANCEL — using the state ID echoed back to it as cnr_stateid — can hit _free_cpntf_state_locked() and call list_del() on that zeroed list head, oopsing the server. Impact is availability only (kernel panic / NFS service outage), with no confidentiality or integrity impact, and exploitation requires no privileges or user interaction per the CVSS vector (7.5, AV:N/AC:L/PR:N). Any Linux system running nfsd with NFSv4.2 reachable by clients — enterprise file servers, NAS/storage stacks, and hypervisor or compute hosts exporting NFS — is potentially affected; no public PoC is known and the flaw is not listed in CISA's KEV catalog.

What to do: Upgrade to a Linux kernel containing the upstream fix once your distribution ships it (check for a kernel update that includes the nfsd cpntf publish-race fix in nfs4_init_cp_state). Until patched, restrict NFSv4.2 access to trusted client hosts only — firewall TCP 2049 and avoid exporting to untrusted or multi-tenant machines — and watch dmesj/dmesg for nfsd-related oopses indicating crash attempts. The bug is denial-of-service only (no data theft or tampering), so prioritize based on how exposed your NFSv4.2 exports are to less-trusted clients.

Affected
Linux Kernel (nfsd, NFSv4.2 server-to-server copy / copy-notify state handling)
Estimated exposure
large≈ hundreds of thousands of NFS-serving Linux hosts worldwide (tens of thousands of NFS endpoints visible on TCP/2049 in public internet scans), reachable by… — Linux nfsd is the dominant NFS server implementation in enterprise and datacenter storage, and while public scans (Shodan/Censys) show on the order of tens of thousands of internet-reachable port-2049 NFS endpoints, the far larger exposure…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.

Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

In the news

No ingested article mentions this CVE yet.