CVE-2026-72472: nfs: use nfsi->rwsem to protect traversal of the file lock list

In the Linux kernel, the following vulnerability has been resolved:

nfs: use nfsi->rwsem to protect traversal of the file lock list

Lingfeng identified a bug and suggested two solutions, but both appear to have issues.

Generally, we cannot release flclock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfsdelegationclaimlocks and nfs4reclaimlocks cannot adhere to this rule because recoverlock or nfs4lockdelegationrecall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfsreclaimlocks follows this approach. Although nfsdelegationclaimlocks uses sodelegreturnmutex instead, this is inadequate since a single inode can have multiple nfs4state instances. Therefore, the fix is to also use nfsi->rwsem in this case.

Furthermore, after commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), the functions nfs4lockudone and nfs4lockdone also break this rule because they call lockslockinodewait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to lockslockinodewait is moved into nfs4procsetlk. Regarding the bug fixed by commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), it has been resolved after commit 0460253913e5 ("NFSv4: nfs4doopen() is incorrectly triggering state recovery") because all slots are drained before calling nfs4doreclaim, which prevents concurrent stateid changes along this path. Also, nfsdelegationclaimlocks does not cause this concurrency either since when nfs4procsetlk is called with NFSDELEGATEDSTATE, no RPC is sent, so nfs4lockdone is not called. Therefore, nfs4lockdelegationrecall from nfsdelegationclaimlocks is the first time the stateid is set.