CVE-2026-90102: NFSv4/pnfs: key the data server cache on the NFS version
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pnfs: key the data server cache on the NFS version
nfs4pnfsdsadd() keys the per-net data server cache on the multipath address set alone, and struct nfs4pnfsds 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 dsversions[0].version therefore share a single nfs4pnfsds, and whichever mirror connects first pins dsclp to its own version. The other one is handed that client anyway, so it selects rpccallops 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 nfs4pnfsds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpccallops and rpcops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (NFSv4/pnfs)to a version that resolves this vulnerability.Patch NULL
Event History
Frequently Asked Questions
Which deployments are exposed to this failure?
The issue affects pNFS flexfiles deployments where a single data-server address legitimately serves both NFSv3 and NFSv4, and device information causes mirrors with different major NFS versions to use that same address. The files layout driver is not subject to the mixed-version condition because it always connects using NFSv4.
What conditions trigger the crash?
Two device IDs on the same data-server address must have different ds_versions[0].version values. If one mirror connects first, its NFS client is reused for the other mirror despite the version mismatch; the resulting mismatched sequence-slot handling can dereference NULL.
Does a difference between NFSv4.0 and NFSv4.1 trigger this issue?
No. The relevant cache separation is by major NFS version, because that selects the RPC operations; NFSv4.0 and NFSv4.1 continue to share a client.