CVE-2026-90102 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pnfs: key the data server cache on the NFS version
nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4.
Two deviceids on one address with different ds_versions[0].version
therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL.
Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability resides within the Linux kernel's implementation of Network File System version four parallel NFS, specifically affecting the data server cache management logic in the pnfs subsystem. This issue arises from an incomplete keying mechanism used to identify and manage connections to remote storage devices. The function nfs4_pnfs_ds_add is responsible for registering a new data server connection into a per-network namespace cache. However, it currently uses only the multipath address set as the unique identifier for this cache entry. This design assumes that each network address corresponds to a single NFS protocol version, which holds true for the files layout driver since it strictly enforces connections using NFSv4. Nevertheless, this assumption fails in environments utilizing the flexfiles layout driver, where a single physical or virtual IP address may legitimately serve clients over different major versions of the NFS protocol, such as both NFSv3 and NFSv4 simultaneously.
When two distinct device identifiers associated with the same network address but requesting different data server versions attempt to register their connections, they incorrectly map to the same nfs4_pnfs_ds structure within the cache. The first connection to establish itself successfully pins the client pointer ds_clp to its specific protocol version configuration. Consequently, when a second request arrives for the same address but with a differing major NFS version, it is handed this pre-existing client instance rather than creating or retrieving a separate one appropriate for its required version. This leads to a critical state mismatch where the connection attempts to utilize rpc_call_ops and other operational structures associated with the wrong protocol version.
The immediate technical consequence of this misconfiguration is a null pointer dereference during sequence-slot handling operations. Because the client structure was initialized for a different NFS major version, it lacks the necessary context or initialization data expected by the current operation's code path. When the kernel attempts to access fields within this mismatched structure that are not populated due to the version discrepancy, it encounters an uninitialized or null pointer. This results in a kernel panic or system crash, effectively causing a denial of service for any workload relying on parallel NFS with mixed-version configurations over shared addresses.
To resolve this issue, the caching logic has been updated to include the major NFS protocol version as part of the cache key alongside the multipath address set. By incorporating the version into the lookup criteria, the system ensures that distinct versions targeting the same IP address are treated as separate entities within the data server cache. This allows each mirror connection to maintain its own dedicated nfs4_pnfs_ds structure and corresponding client instance tailored to its specific protocol requirements. The comparison logic focuses exclusively on the major version number because this is the primary determinant for selecting the appropriate rpc_call_ops and rpc_ops structures, meaning that NFSv4.0 and NFSv4.1 can still share a single client context without risk of conflict while maintaining operational integrity across different major versions.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation as it involves the failure to adequately validate or distinguish input parameters (specifically protocol version) when constructing cache keys for resource management. It also relates to CWE-416 Use After Free in a broader sense of improper state handling leading to invalid memory access, though more accurately described by CWE-825 Expired Pointer Dereference due to the use of an incorrectly initialized object structure. In terms of adversarial tactics, this flaw could be leveraged for Denial of Service attacks under MITRE ATT&CK technique T1499 Endpoint Denial of Service if exploited remotely or locally by a privileged user capable of triggering pnfs data server connections with conflicting version requirements. Mitigation strategies involve applying the kernel patch that updates the cache keying mechanism to include protocol version information, ensuring strict separation of connection states for different NFS major versions sharing common network endpoints.