https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Tue, 05 May 2026 22:24:04 +0000 https://vulnerability.circl.lu/sighting/ce3a8f5b-fcfb-42cc-99f2-c4d00e64e5cd/export {"uuid": "ce3a8f5b-fcfb-42cc-99f2-c4d00e64e5cd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52909", "type": "seen", "source": "https://t.me/cvedetector/3750", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2023-52909 - Linux Kernel NFSidor Server File System Handling Vulnerability\", \n \"Content\": \"CVE ID : CVE-2023-52909 \nPublished : Aug. 21, 2024, 7:15 a.m. | 35\u00a0minutes ago \nDescription : 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. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"21 Aug 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T09:52:15.000000Z"} {"uuid": "ce3a8f5b-fcfb-42cc-99f2-c4d00e64e5cd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52909", "type": "seen", "source": "https://t.me/cvedetector/3750", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2023-52909 - Linux Kernel NFSidor Server File System Handling Vulnerability\", \n \"Content\": \"CVE ID : CVE-2023-52909 \nPublished : Aug. 21, 2024, 7:15 a.m. | 35\u00a0minutes ago \nDescription : 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. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"21 Aug 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T09:52:15.000000Z"} https://vulnerability.circl.lu/sighting/ce3a8f5b-fcfb-42cc-99f2-c4d00e64e5cd/export Wed, 21 Aug 2024 09:52:15 +0000