{"id":"CVE-2026-72472","summary":"nfs: use nfsi-\u003erwsem to protect traversal of the file lock list","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: use nfsi-\u003erwsem to protect traversal of the file lock list\n\nLingfeng identified a bug and suggested two solutions, but both appear\nto have issues.\n\nGenerally, we cannot release flc_lock while iterating over the file lock\nlist to avoid use-after-free (UAF) problems with file locks. However,\nfunctions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot\nadhere to this rule because recover_lock or nfs4_lock_delegation_recall\nmay take a long time. To resolve this, NFS switches to using nfsi-\u003erwsem\nfor the same protection, and nfs_reclaim_locks follows this approach.\nAlthough nfs_delegation_claim_locks uses so_delegreturn_mutex instead,\nthis is inadequate since a single inode can have multiple nfs4_state\ninstances. Therefore, the fix is to also use nfsi-\u003erwsem in this case.\n\nFurthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range\nlock must be atomic with the stateid update\"), the functions\nnfs4_locku_done and nfs4_lock_done also break this rule because they\ncall locks_lock_inode_wait without holding nfsi-\u003erwsem. Simply adding\nthis protection could cause many deadlocks, so instead, the call to\nlocks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug\nfixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range\nlock must be atomic with the stateid update\"), it has been resolved\nafter commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering\nstate recovery\") because all slots are drained before calling\nnfs4_do_reclaim, which prevents concurrent stateid changes along this path.\nAlso, nfs_delegation_claim_locks does not cause this concurrency either\nsince when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is\nsent, so nfs4_lock_done is not called. Therefore,\nnfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first\ntime the stateid is set.","modified":"2026-08-18T03:56:43.773539527Z","published":"2026-08-15T05:57:13.752Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72472.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/1cda95bf2e9c0e6b63545b7565fe4a1e474322f4"},{"type":"WEB","url":"https://git.kernel.org/stable/c/4837fb36219e6c08b666bc31a86841bad8526358"},{"type":"WEB","url":"https://git.kernel.org/stable/c/e68035178e65e2b3aa386ce61202ff33724ae418"},{"type":"WEB","url":"https://git.kernel.org/stable/c/f161ef7b0dd2f51fdb002ba4a4e9bf0ee7409218"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72472.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72472"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"c69899a17ca4836230720e65493942d9582a0424"},{"fixed":"1cda95bf2e9c0e6b63545b7565fe4a1e474322f4"},{"fixed":"f161ef7b0dd2f51fdb002ba4a4e9bf0ee7409218"},{"fixed":"e68035178e65e2b3aa386ce61202ff33724ae418"},{"fixed":"4837fb36219e6c08b666bc31a86841bad8526358"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72472.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.0.0"},{"fixed":"6.12.97"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.40"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.1.5"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72472.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}