Linux Kernel EUVD-2026-86234

Requires local access to a Linux host running the in-kernel NFS server (nfsd) with the ability to invoke the nfsd netlink rpc_status_get dump operation, AND the host must run on a weakly-ordered architecture (ARM or POWER) - the description states the reordering does not occur on strongly-ordered CPUs such as x86/x86_64, which effectively eliminates exploitability there. The attacker must also win a timing race against nfsd_dispatch concurrently modifying the status fields (active NFS traffic), so a live NFS workload is a practical prerequisite. These factors - local-only vector, low-privilege netlink access, architecture restriction, and the need to hit a narrow race window - sharply limit realistic exploitation.

This is a Linux kernel nfsd data race (missing smp_rmb() in a hand-rolled seqcount retry in nfsd_nl_rpc_status_get_dumpit) with a provided CVSS 3.1 vector of AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H (7.1). All exploitation signals point to LOW real-world priority despite the 7.1 base score: attack vector is Local (AV:L), it requires low-privilege access to the nfsd netlink interface, and it is only observable on weakly-ordered architectures (ARM, POWER) - the description explicitly states x86 is not affected because it does not reorder these reads. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation status is: no public exploit identified at time of analysis. The vendor CVSS AC:L conflicts with the nature of the flaw - winning a memory-reordering race against a concurrent writer within a narrow window is not low-complexity, so AC:H is more defensible. The C:H/A:H impacts also look overstated: a torn read of status fields realistically leaks a small amount of inconsistent kernel data (C:L) and, at worst, a torn pointer dereference could crash (A:L), not the full high-impact the vector implies. Net: a legitimate correctness/hardening fix, not an urgent operational threat.

A local, low-privileged user on an ARM or POWER host running an NFS server repeatedly issues the nfsd netlink rpc_status_get dump operation while NFS RPCs are actively being dispatched, racing the concurrent field updates. On a weakly-ordered CPU the retry check can pass even though the fields were concurrently mutated, so the reader observes torn/inconsistent RPC status data, potentially leaking stale kernel field contents or dereferencing an inconsistent value. No public exploit exists and the race is not reproducible on strongly-ordered x86.