CVE-2026-93229 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
nfsd: add missing read barrier to rpc_status_get dumpit seqcount retry
The hand-rolled seqcount-like protocol in nfsd_nl_rpc_status_get_dumpit() is missing a read memory barrier (smp_rmb) before its second counter check. The standard kernel read_seqcount_retry() includes smp_rmb() 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 smp_rmb() 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 smp_load_acquire() already pairs with the smp_store_release() in nfsd_dispatch(); with the smp_rmb() now ordering the field reads, the retry check no longer needs acquire semantics and reads the counter with a plain READ_ONCE(), as read_seqcount_retry() does.
[ cel: Use READ_ONCE instead of smp_load_acquire() ]
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel vulnerability identified in the nfsd subsystem involves a critical memory ordering defect within the rpc_status_get dumpit sequence count retry logic. This issue stems from an implementation detail where developers utilized a hand-rolled seqcount-like protocol rather than relying on standard kernel primitives for managing concurrent access to shared data structures. Specifically, the function nfsd_nl_rpc_status_get_dumpit() was missing a read memory barrier, denoted as smp_rmb(), prior to its second counter check during the retry loop. In systems utilizing weakly-ordered architectures such as ARM and POWER, CPUs are permitted to reorder memory operations for performance optimization unless explicit barriers enforce strict ordering constraints. Without this specific barrier, there is no guarantee that field reads will complete before the sequence counter is re-evaluated, creating a window where stale or partially updated data can be observed by readers even when the writer has signaled completion through consistent counter values.
The technical flaw lies in the absence of proper synchronization primitives to enforce memory visibility across cores. The standard kernel function read_seqcount_retry() inherently includes an smp_rmb() call to ensure that all subsequent data reads are ordered after the initial sequence count check and before any potential retry logic re-checks the counter for consistency. By omitting this barrier, the custom implementation failed to prevent instruction reordering on architectures where such reordering is permissible. Consequently, a reader thread could observe a consistent pair of sequence counters indicating that no write was in progress, yet still read field values that were concurrently being modified by a writer thread. This race condition undermines the integrity of the data structure, potentially leading to corrupted status reports or unpredictable behavior within the NFS daemon subsystem when handling network requests.
The operational impact of this vulnerability is primarily related to data consistency and potential information leakage in distributed file system environments. While immediate exploitation for arbitrary code execution may be difficult due to the nature of the affected component being a diagnostic dump function, the corruption of status data can lead to service degradation or incorrect state reporting to management tools relying on nfsd statistics. In high-concurrency scenarios typical of production NFS servers, this race condition could manifest intermittently, making it challenging to reproduce and diagnose without specialized debugging tools. The lack of proper memory ordering means that applications querying RPC status might receive inconsistent snapshots, which can affect monitoring systems or automated scaling decisions based on real-time server load metrics derived from these statistics.
To mitigate this vulnerability, the kernel developers have implemented a fix by inserting an smp_rmb() call before the second counter check within the retry logic. This addition ensures that all field reads are ordered ahead of the sequence count verification, effectively matching the barrier semantics provided by standard seqcount read-side implementations. Furthermore, the patch refactors the begin-side synchronization to use READ_ONCE instead of smp_load_acquire(), as the acquire semantics were rendered unnecessary once proper ordering was established via the explicit memory barrier and the existing pairing with smp_store_release in nfsd_dispatch(). This change aligns the custom implementation with kernel best practices for handling concurrent data access, ensuring that readers always see a consistent view of the data structure relative to the writer's operations.
From a vulnerability classification perspective, this issue maps directly to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). The specific mechanism involves improper ordering of memory accesses in a multi-threaded environment, which is characteristic of race conditions arising from missing synchronization primitives on weakly-ordered architectures. In terms of the MITRE ATT&CK framework, this vulnerability relates to techniques involving resource manipulation and potential information discovery through inconsistent state observation. Although it does not directly facilitate privilege escalation or remote code execution in its current form, it represents a fundamental flaw in concurrency control that could be leveraged in conjunction with other vulnerabilities to achieve more severe outcomes such as denial of service through data corruption or logic bypasses if the status data is used for security decisions.
System administrators and developers should ensure that their Linux kernels are updated to include this patch, particularly those running on ARM or POWER architectures where weak memory ordering models make such synchronization errors most impactful. Regular auditing of kernel code for proper use of seqcount primitives and memory barriers can help prevent similar issues in custom subsystems. The resolution demonstrates the importance of adhering to established kernel APIs like read_seqcount_retry() rather than implementing ad-hoc locking mechanisms, as these standard functions encapsulate complex architectural considerations that are prone to error when manually replicated. Maintaining strict adherence to concurrency best practices is essential for preserving data integrity and system stability in high-performance server environments.