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 nfsdfile can end up with its PENDING bit cleared while the nf is hashed, and the nffile pointer is still zeroed out. Other tasks can find it in this state and they expect to see a valid nffile, and can oops if nffile is NULL.
Also, there is no guarantee that we'll end up creating a new nfsdfile if one is already in the hash. If an extant entry is in the hash with a valid nffile, nfs4getvfsfile will clobber its nffile pointer with the value of opfile and the old nffile will leak.
Fix both issues by making a new nfsdfileacquireiopened 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 nfsdfile already has a valid nffile, we'll just ignore the optional file and pass the nfsdfile 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.