In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix handling of cached open files in nfsd4_open codepath
Commit fb70bf124b05 (“NFSD: Instantiate a struct file when creating a
regular NFSv4 file”) added the ability to cache an open fd over a
compound. There are a couple of problems with the way this currently
works:
It’s racy, as a newly-created nfsd_file can end up with its PENDING bit
cleared while the nf is hashed, and the nf_file pointer is still zeroed
out. Other tasks can find it in this state and they expect to see a
valid nf_file, and can oops if nf_file is NULL.
Also, there is no guarantee that we’ll end up creating a new nfsd_file
if one is already in the hash. If an extant entry is in the hash with a
valid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with
the value of op_file and the old nf_file will leak.
Fix both issues by making a new nfsd_file_acquirei_opened variant that
takes an optional file pointer. If one is present when this is called,
we’ll take a new reference to it instead of trying to open the file. If
the nfsd_file already has a valid nf_file, we’ll just ignore the
optional file and pass the nfsd_file back as-is.
Also rework the tracepoints a bit to allow for an “opened” variant and
don’t try to avoid counting acquisitions in the case where we already
have a cached open file.
git.kernel.org/linus/0b3a551fa58b4da941efeb209b3770868e2eddd7 (6.2-rc4)
git.kernel.org/stable/c/0b3a551fa58b4da941efeb209b3770868e2eddd7
git.kernel.org/stable/c/0b778361998d6c6356b8d2fc7ddf025fb3224654
git.kernel.org/stable/c/45c08a752982116f3287afcd1bd9c50f4fab0c28
git.kernel.org/stable/c/973acfdfe90c8a4e58ade97ff0653a498531ff2e
launchpad.net/bugs/cve/CVE-2023-52909
nvd.nist.gov/vuln/detail/CVE-2023-52909
security-tracker.debian.org/tracker/CVE-2023-52909
www.cve.org/CVERecord?id=CVE-2023-52909