nfsd: fix handling of cached open files in nfsd4_open codepath
CVSS score
7.5
EPSS probability
%0.6
Risk score
0.0
Published
2 y ago
Etkilenen ürün ve sürüm için yayımlanan güvenlik güncellemesini uygulayın.
Impact on My Inventory
Only the personal products you have added to your account are assessed; an organisation's inventory does not appear here.
Checking session…
Vulnerability description
DayBreach CVE AI Research
CVE-2023-52909 has vendor, distribution, patch and security-source records on file. We can compare them and prepare an explanation linked to the evidence.
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.
IMPACT: Affected Products and Software
RED HAT CSAF/VEX: Product Impact Check
SCORING: CVSS from Multiple Sources
CVSS Scores
The Common Vulnerability Scoring System is a standardised framework for assessing the severity of vulnerabilities in software and systems. We collect and display CVSS scores from several sources for each CVE.
| SCORE | VERSION | SEVERITY | VECTOR | SOURCE |
|---|---|---|---|---|
| 7.5 | CVSS V3_1 | HIGH | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | CVE CNA |
| 7.5 | CVSS V31 | HIGH | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | NVD |
| 4.7 | CVSS V31 | MEDIUM | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H | NVD |
Patch and Remediation Guide
Solution & Remediation Advisory
4 doğrulanmış yama veya düzeltilmiş sürüm kanıtı bulundu.
Public exploit and active exploitation status
Verified exploit intelligence
No verified public PoC, exploit repository or Metasploit module has been found for this CVE yet.
Weakness Classification and Attack Patterns (CWE & CAPEC)
CWE - Common Weakness Enumeration
While CVE identifies specific instances of vulnerabilities, CWE categorises the common flaws or weaknesses that can lead to vulnerabilities. CVE-2023-52909 is associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2023-52909 weaknesses.
Attack Vector and Accessibility
Official Sources and Advisories
Similar Vulnerabilities
Get this vulnerability through the API
Affected products, version ranges, exploitation status and patch information in a single request, with a free key.
curl -H "x-api-key: $DAYBREACH_API_KEY" \ "https://api.daybreach.dev/api/v1/intel/cves/CVE-2023-52909"