Cloudanix VulnDB

CVE-2026-89681

Critical · 9.8

CVSS

9.8

EPSS

0.6%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel's network file-sharing code can let remote attackers gradually drain server resources and cause instability without needing login credentials.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in nfsd layout fence worker allows delayed_work_pending() to return false while the worker runs, enabling duplicate sc_count reference via a coalesced second worker; the extra reference is never released, leaking layout stateid objects.

Why it matters to the business

NFS servers may suffer gradual memory exhaustion or stateid resource leaks under load, leading to degraded file-sharing performance, eventual service instability, or crashes; high network exposure increases urgency for kernel updates despite low observed exploitation.

How an attack unfolds

An attacker with network access to an NFS server triggers concurrent layout operations that race the fence worker scheduling path, causing the duplicate reference and stateid leak without requiring authentication or special client state.

How to fix it

Apply the upstream kernel patch that replaces the racy delayed_work_pending() check with an ls_fence_inflight boolean protected by ls_lock and refcount_inc_not_zero(); rebuild and deploy updated kernels to all affected systems; test NFS workloads post-upgrade.

How to confirm the fix worked

Confirm the patch is present by inspecting nfsd/layout.c for the ls_fence_inflight atomic handling and removal of self-rearming mod_delayed_work(); run regression tests exercising layout fencing and delayed work paths under concurrency; monitor for stateid reference counts stabilizing under load.

Typical attack path

  1. Establish unauthenticated NFSv4.x connection to target server
  2. Issue layout-related operations that invoke lm_breaker_timedout under timing conditions matching the workqueue window
  3. Trigger repeated fence events to accumulate leaked stateids
  4. Observe or accelerate resource exhaustion on the server

How to detect it

Search kernel logs and audit trails for repeated nfsd layout fence worker scheduling anomalies, stateid allocation spikes without corresponding releases, or workqueue race warnings; correlate with NFSv4 layout request patterns from untrusted clients.

What your security team should do

  • Prioritize kernel updates on all internet-facing or multi-tenant NFS servers within normal change windows
  • Enable kernel live-patching where available for critical production systems
  • Review NFS export configurations to limit exposure while patches are applied
  • Add monitoring for unusual stateid allocation rates or memory growth in nfsd processes

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix layout fence worker double-reference race The workqueue core clears WORK_STRUCT_PENDING before the callback is invoked, so delayed_work_pending() in lm_breaker_timedout() can return false while the fence worker is already running. This lets the breaker take a duplicate sc_count reference and schedule a new worker that coalesces with the in-progress one. The extra reference is never put, leaking the layout stateid. Replace the racy delayed_work_pending() check with an ls_fence_inflight boolean set atomically with refcount_inc_not_zero() under ls_lock, and cleared under ls_lock before the final nfs4_put_stid() on the dispose path; the retry path intentionally retains it. Remove the self-rearm mod_delayed_work() at the top of the worker.

Affected packages

Ecosystem Package Introduced Fixed