ZeroHour

CVE-2026-89705

large

Linux kernel nfsd seq-lock flaw leads to out-of-bounds kernel memory read

CVSS 3.1
7.1 high
EPSS
Published
()
Modified
AI analysis

The Linux kernel's NFS server (nfsd) fails to restore the request status counter to an even value on the cache-hit (RC_REPLY), drop (RC_DROPIT / RQ_DROPME), and encode-error exit paths of nfsd_dispatch(), breaking a seq-lock protocol that guards a lockless reader in nfsd_nl_rpc_status_get_dumpit(). Once the counter is stuck odd, that reader can no longer detect concurrent mutation of the request and can read actively changing fields, including reading past the end of the 8-element inline ops array — an out-of-bounds read in kernel space. Per the CVSS 3.1 vector (7.1, local attack vector, low privileges required), an attacker able to reach a vulnerable NFS server can obtain kernel memory disclosure (C:H) and potentially crash the kernel (A:H). Systems running kernels that contain nfsd's rq_status_counter / rpc-status netlink code and that actively serve NFS are affected. There is no public proof of concept and no known exploitation in the wild.

What to do: Patch to a kernel carrying the fix, which adds a helper that advances rq_status_counter to the next even value on every nfsd_dispatch() exit path after the odd-valued store; monitor your distribution's stable kernel updates for the backport. If NFS serving is not required on a host, do not load the nfsd module so the vulnerable path is unreachable. On NFS servers, restrict local shell access and netlink/CAP_NET_ADMIN privileges, and watch kernel logs for oopses or crashes originating in nfsd dispatch and rpc-status dump paths.

Affected
Linux kernel (nfsd)
Estimated exposure
large≈200,000+ internet-exposed NFS services, plus a substantially larger unknown population of internal enterprise NFS servers — Public internet scans (e.g., Shodan) typically show on the order of a couple hundred thousand devices with NFS port 2049 exposed, and private enterprise NFS deployments are far more numerous, though the exact affected kernel-version range…

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: 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.

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

In the news

No ingested article mentions this CVE yet.