ghsa-qw5v-wmjr-8fpc
Vulnerability from github
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.
{
"affected": [],
"aliases": [
"CVE-2023-52909"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T07:15:06Z",
"severity": "MODERATE"
},
"details": "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\u0027s 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\u0027ll 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\u0027ll take a new reference to it instead of trying to open the file. If\nthe nfsd_file already has a valid nf_file, we\u0027ll 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\u0027t try to avoid counting acquisitions in the case where we already\nhave a cached open file.",
"id": "GHSA-qw5v-wmjr-8fpc",
"modified": "2024-09-12T15:32:59Z",
"published": "2024-08-21T09:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52909"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b3a551fa58b4da941efeb209b3770868e2eddd7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b778361998d6c6356b8d2fc7ddf025fb3224654"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45c08a752982116f3287afcd1bd9c50f4fab0c28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/973acfdfe90c8a4e58ade97ff0653a498531ff2e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.