Cloudanix VulnDB

CVE-2026-89705

High · 7.1

CVSS

7.1

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel handles certain NFS server requests can let a local user read or corrupt memory that should be protected, risking crashes or data leaks.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in nfsd_dispatch leaves rq_status_counter odd on cache-hit, drop, and encode-error paths, allowing the lockless nfsd_nl_rpc_status_get_dumpit reader to observe partially-updated compound request state and read past the end of the 8-element inline ops array.

Why it matters to the business

Local users on NFS servers can trigger kernel memory corruption or information disclosure, leading to crashes, denial of service, or potential privilege escalation on affected Linux systems.

How an attack unfolds

An attacker with local access issues NFS requests that hit cache, drop, or encode-error paths in nfsd_dispatch, leaving the status counter odd; a concurrent netlink status dump then reads stale or out-of-bounds ops data without detecting the mutation.

How to fix it

Apply the upstream kernel patch that restores rq_status_counter to the next even value on every post-odd-store exit path; rebuild and deploy the fixed kernel; reboot affected systems.

How to confirm the fix worked

Confirm the helper advancing the counter to the next even value is present on all return paths after the odd store; run regression tests exercising cache-hit, drop, and encode-error paths while monitoring for OOB accesses.

Typical attack path

  1. Obtain local unprivileged access on an NFS server host
  2. Issue crafted NFS compound requests that trigger RC_REPLY, RC_DROPIT, or encode-error return paths
  3. Concurrently invoke nfsd_nl_rpc_status_get_dumpit via netlink
  4. Trigger out-of-bounds read of args->ops beyond the inline array during decode or release

How to detect it

Inspect kernel logs for oops or slab-out-of-bounds messages referencing nfsd compound ops; correlate netlink status dump calls with NFS request error paths; look for repeated odd rq_status_counter values in debug traces.

What your security team should do

  • Prioritize kernel updates on all systems exposing NFS services
  • Restrict local unprivileged access where possible until patched
  • Monitor netlink and NFS dispatch paths for anomalous status queries

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: restore rq_status_counter to even on all nfsd_dispatch() exit paths nfsd_dispatch() sets rq_status_counter to an odd value once a request has been decoded, and back to an even value once it has been fully processed, forming a seq-lock like protocol with the lockless reader in nfsd_nl_rpc_status_get_dumpit(). Only the fully successful path restored the counter to even. The cache-hit (RC_REPLY), drop (RC_DROPIT / RQ_DROPME) and encode-error paths all return after the odd-valued store without ever bringing the counter back to even. Once one of those paths is taken, rq_status_counter is left odd: the next request's decode ORs in 1 (still odd) and only a subsequent successful encode restores even. While stuck odd, the dumpit reader treats the rqstp fields as stable and its retry check compares against the same unchanging odd value, so it never detects concurrent mutation. This exposes actively mutating fields (e.g. args->ops / args->opcnt during compound decode and release) to the lockless reader, which can read past the end of the 8-element inline ops array. Add a helper that advances the counter to the next even value and call it on every return path that follows the odd-valued store. The decode-error path is left untouched as it is reached before the counter is set odd.

Affected packages

Ecosystem Package Introduced Fixed