CVE-2026-93229: nfsd: add missing read barrier to rpc_status_get dumpit seqcount retry
In the Linux kernel, the following vulnerability has been resolved:
nfsd: add missing read barrier to rpcstatusget dumpit seqcount retry
The hand-rolled seqcount-like protocol in nfsdnlrpcstatusgetdumpit() is missing a read memory barrier (smprmb) before its second counter check. The standard kernel readseqcountretry() includes smprmb() to ensure that all data reads complete before the counter is re-checked.
Without this barrier, on weakly-ordered architectures (ARM, POWER), the CPU may reorder field reads past the second counter check, making the retry logic ineffective: it could observe a consistent counter pair while reading fields that have been concurrently modified by the writer.
Add smprmb() before the second counter check to order the field reads ahead of it, matching the barrier semantics of the standard seqcount read-side. The begin-side smploadacquire() already pairs with the smpstorerelease() in nfsddispatch(); with the smprmb() now ordering the field reads, the retry check no longer needs acquire semantics and reads the counter with a plain READONCE(), as readseqcountretry() does.
[ cel: Use READONCE instead of smploadacquire() ]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In nfsd_nl_rpc_status_get_dumpit(), add smp_rmb() before the second counter check to order the field reads; read the counter with READ_ONCE() rather than smp_load_acquire().
Event History
Frequently Asked Questions
Which systems are most exposed to this issue?
Linux kernel systems running NFS server functionality are relevant because the affected code is in nfsd_nl_rpc_status_get_dumpit(). The ordering failure is specifically described on weakly ordered architectures such as ARM and POWER.
What conditions are required for incorrect data to be observed?
A writer must concurrently modify the RPC status fields while the dump operation reads them. Without the missing read barrier, field reads may be reordered after the retry counter check, allowing a seemingly consistent counter pair to accompany concurrently modified field values.
How can I determine whether a fix is present?
Check whether the kernel includes the change that adds smp_rmb() before the second counter check in nfsd_nl_rpc_status_get_dumpit(), with the retry-side counter read changed to READ_ONCE(). The provided stable references identify commits containing the fix.