Cloudanix VulnDB

CVE-2026-89684

High · 7.5

CVSS

7.5

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing flaw in the Linux NFS server can let a client request cause the server to crash, interrupting file sharing until the system restarts.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in NFSv4.2 copy state initialization where an IDR entry is published before its list linkage is complete, allowing a concurrent OFFLOAD_CANCEL to perform list_del on an uninitialized list_head and trigger a kernel oops.

Why it matters to the business

NFS servers can crash under load from legitimate or malicious clients, causing unplanned downtime and loss of file access for users and applications relying on the server.

How an attack unfolds

An attacker capable of issuing NFSv4.2 OFFLOAD_CANCEL operations targets the window between IDR insertion and list_add during state creation; the cancel path reaches the unlinked list_head and dereferences invalid pointers, crashing the kernel.

How to fix it

Apply the upstream fix that moves cs_type assignment and list_add into the same critical section as idr_alloc_cyclic, initializes the list head after allocation, and switches to list_del_init; update to a Linux kernel release containing this change.

How to confirm the fix worked

Confirm the kernel source contains the merged commit that folds the publish and list_add operations; verify no concurrent lookup can observe a partially linked cp_list entry; test by exercising COPY and OFFLOAD_CANCEL paths under concurrency.

Typical attack path

  1. Establish an NFSv4.2 session to the target server
  2. Trigger nfs4_init_cp_state via a COPY operation that allocates but does not yet fully link state
  3. Immediately issue OFFLOAD_CANCEL using the echoed stateid
  4. Kernel executes list_del on a zeroed list_head inside _free_cpntf_state_locked
  5. Resulting oops causes server reboot or panic

How to detect it

Search kernel logs and crash dumps for oops traces containing manage_cpntf_state, _free_cpntf_state_locked, list_del, or nfs4_init_cp_state; correlate with NFSv4.2 COPY and OFFLOAD_CANCEL traffic in packet captures or server audit logs.

  • manage_cpntf_state
  • _free_cpntf_state_locked
  • nfs4_init_cp_state
  • list_del.*cp_list
  • nfs4_alloc_init_cpntf_state

What your security team should do

  • Prioritize kernel upgrades on all exposed NFS servers within the next maintenance window
  • Monitor for kernel oops reports mentioning nfsd cpntf or list_del operations
  • Restrict NFSv4.2 COPY/OFFLOAD features to trusted clients if patching is delayed
  • Review EPSS and exploit maturity; no known in-the-wild exploitation reduces immediate urgency but does not eliminate availability risk

The record

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.

Affected packages

Ecosystem Package Introduced Fixed