{"id":"CVE-2023-52909","state":"PUBLISHED","title":"nfsd: fix handling of cached open files in nfsd4_open codepath","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix handling of cached open files in nfsd4_open codepath\n\nCommit fb70bf124b05 (\"NFSD: Instantiate a struct file when creating a\nregular NFSv4 file\") added the ability to cache an open fd over a\ncompound. There are a couple of problems with the way this currently\nworks:\n\nIt's racy, as a newly-created nfsd_file can end up with its PENDING bit\ncleared while the nf is hashed, and the nf_file pointer is still zeroed\nout. Other tasks can find it in this state and they expect to see a\nvalid nf_file, and can oops if nf_file is NULL.\n\nAlso, there is no guarantee that we'll end up creating a new nfsd_file\nif one is already in the hash. If an extant entry is in the hash with a\nvalid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with\nthe value of op_file and the old nf_file will leak.\n\nFix both issues by making a new nfsd_file_acquirei_opened variant that\ntakes an optional file pointer. If one is present when this is called,\nwe'll take a new reference to it instead of trying to open the file. If\nthe nfsd_file already has a valid nf_file, we'll just ignore the\noptional file and pass the nfsd_file back as-is.\n\nAlso rework the tracepoints a bit to allow for an \"opened\" variant and\ndon't try to avoid counting acquisitions in the case where we already\nhave a cached open file.","publishedAt":"2024-08-21T06:10:50.303Z","updatedAt":"2026-08-05T09:11:55.987Z","severity":{"score":7.5,"label":"High","version":"3.1","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","source":"Linux"},"assigner":"Linux","products":["Linux Linux"],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"c20097329d2c196b818c4666c7820c1378d69d61","status":"affected","lessThan":"45c08a752982116f3287afcd1bd9c50f4fab0c28","versionType":"git"},{"version":"106331a12b0fa5afa6995b1f9ebb03ddcaac6915","status":"affected","lessThan":"0b778361998d6c6356b8d2fc7ddf025fb3224654","versionType":"git"},{"version":"fb70bf124b051d4ded4ce57511dfec6d3ebf2b43","status":"affected","lessThan":"973acfdfe90c8a4e58ade97ff0653a498531ff2e","versionType":"git"},{"version":"fb70bf124b051d4ded4ce57511dfec6d3ebf2b43","status":"affected","lessThan":"0b3a551fa58b4da941efeb209b3770868e2eddd7","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/nfsd/filecache.c","fs/nfsd/filecache.h","fs/nfsd/nfs4state.c","fs/nfsd/trace.h"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"5.19","status":"affected"},{"version":"0","status":"unaffected","lessThan":"5.19","versionType":"semver"},{"version":"6.1.7","status":"unaffected","lessThanOrEqual":"6.1.*","versionType":"semver"},{"version":"6.2","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/nfsd/filecache.c","fs/nfsd/filecache.h","fs/nfsd/nfs4state.c","fs/nfsd/trace.h"]}],"references":["https://git.kernel.org/stable/c/45c08a752982116f3287afcd1bd9c50f4fab0c28","https://git.kernel.org/stable/c/0b778361998d6c6356b8d2fc7ddf025fb3224654","https://git.kernel.org/stable/c/973acfdfe90c8a4e58ade97ff0653a498531ff2e","https://git.kernel.org/stable/c/0b3a551fa58b4da941efeb209b3770868e2eddd7"],"weaknesses":[],"ingestedAt":"2026-10-29T20:06:33.064Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2023/52xxx/CVE-2023-52909.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2023-52909","state":"PUBLISHED","datePublished":"2024-08-21T06:10:50.303Z","dateUpdated":"2026-08-05T09:11:55.987Z","assignerShortName":"Linux","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateReserved":"2024-08-21T06:07:11.015Z"},"containers":{"cna":{"title":"nfsd: fix handling of cached open files in nfsd4_open codepath","descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix handling of cached open files in nfsd4_open codepath\n\nCommit fb70bf124b05 (\"NFSD: Instantiate a struct file when creating a\nregular NFSv4 file\") added the ability to cache an open fd over a\ncompound. There are a couple of problems with the way this currently\nworks:\n\nIt's racy, as a newly-created nfsd_file can end up with its PENDING bit\ncleared while the nf is hashed, and the nf_file pointer is still zeroed\nout. Other tasks can find it in this state and they expect to see a\nvalid nf_file, and can oops if nf_file is NULL.\n\nAlso, there is no guarantee that we'll end up creating a new nfsd_file\nif one is already in the hash. If an extant entry is in the hash with a\nvalid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with\nthe value of op_file and the old nf_file will leak.\n\nFix both issues by making a new nfsd_file_acquirei_opened variant that\ntakes an optional file pointer. If one is present when this is called,\nwe'll take a new reference to it instead of trying to open the file. If\nthe nfsd_file already has a valid nf_file, we'll just ignore the\noptional file and pass the nfsd_file back as-is.\n\nAlso rework the tracepoints a bit to allow for an \"opened\" variant and\ndon't try to avoid counting acquisitions in the case where we already\nhave a cached open file."}],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"c20097329d2c196b818c4666c7820c1378d69d61","status":"affected","lessThan":"45c08a752982116f3287afcd1bd9c50f4fab0c28","versionType":"git"},{"version":"106331a12b0fa5afa6995b1f9ebb03ddcaac6915","status":"affected","lessThan":"0b778361998d6c6356b8d2fc7ddf025fb3224654","versionType":"git"},{"version":"fb70bf124b051d4ded4ce57511dfec6d3ebf2b43","status":"affected","lessThan":"973acfdfe90c8a4e58ade97ff0653a498531ff2e","versionType":"git"},{"version":"fb70bf124b051d4ded4ce57511dfec6d3ebf2b43","status":"affected","lessThan":"0b3a551fa58b4da941efeb209b3770868e2eddd7","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/nfsd/filecache.c","fs/nfsd/filecache.h","fs/nfsd/nfs4state.c","fs/nfsd/trace.h"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"5.19","status":"affected"},{"version":"0","status":"unaffected","lessThan":"5.19","versionType":"semver"},{"version":"6.1.7","status":"unaffected","lessThanOrEqual":"6.1.*","versionType":"semver"},{"version":"6.2","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/nfsd/filecache.c","fs/nfsd/filecache.h","fs/nfsd/nfs4state.c","fs/nfsd/trace.h"]}],"references":[{"url":"https://git.kernel.org/stable/c/45c08a752982116f3287afcd1bd9c50f4fab0c28"},{"url":"https://git.kernel.org/stable/c/0b778361998d6c6356b8d2fc7ddf025fb3224654"},{"url":"https://git.kernel.org/stable/c/973acfdfe90c8a4e58ade97ff0653a498531ff2e"},{"url":"https://git.kernel.org/stable/c/0b3a551fa58b4da941efeb209b3770868e2eddd7"}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":7.5,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:N - The bug is in the NFSv4 OPEN/CREATE path (nfsd4_open → nfs4_get_vfs_file → nfsd_file_create) on the in-kernel NFS server, reachable over the network via RPC to nfsd.\nAC:L - The race is between clearing NFSD_FILE_PENDING with nf_file still NULL and the later assignment of op_filp; an attacker can drive both sides with concurrent OPEN(CREATE)/OPEN requests for the same file and credentials.\nPR:N - Typical nfsd deployments use AUTH_SYS/AUTH_NULL with IP-based exports, so a remote peer that can reach the export can establish a clientid and trigger OPEN without real authentication.\nUI:N - Exploitation requires only attacker-sent NFS compounds; no victim user action is needed.\nS:U - Impact is confined to the NFS server kernel (oops/DoS or a struct file leak); it does not cross a separate security authority such as a VM or IOMMU boundary.\nC:N - The primary failure is a NULL pointer dereference of nf_file leading to an oops; there is no information disclosure or UAF read primitive.\nI:N - The bug causes a crash and a possible nf_file pointer leak/clobber without freeing the old file, not a write primitive or control-flow hijack.\nA:H - Concurrent lookups can call file_inode(nf->nf_file) while nf_file is still NULL, causing a kernel oops and denial of service of the NFS server."}]}],"providerMetadata":{"shortName":"Linux","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateUpdated":"2026-08-05T09:11:55.987Z"},"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.19","versionEndExcluding":"6.1.7"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.19","versionEndExcluding":"6.2"}]}]}],"x_generator":{"engine":"bippy-1.2.0"}},"adp":[{"title":"CISA ADP Vulnrichment","metrics":[{"other":{"type":"ssvc","content":{"id":"CVE-2023-52909","role":"CISA Coordinator","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"version":"2.0.3","timestamp":"2024-09-10T16:03:02.157963Z"}}}],"providerMetadata":{"shortName":"CISA-ADP","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","dateUpdated":"2024-09-12T17:33:12.921Z"}}]}}}