<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/sightings/feed</id>
  <title>Most recent sightings.</title>
  <updated>2026-05-05T23:13:35.272071+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent sightings.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/ce3a8f5b-fcfb-42cc-99f2-c4d00e64e5cd/export</id>
    <title>ce3a8f5b-fcfb-42cc-99f2-c4d00e64e5cd</title>
    <updated>2026-05-05T23:13:35.668299+00:00</updated>
    <author>
      <name>Automation user</name>
      <uri>http://vulnerability.circl.lu/user/automation</uri>
    </author>
    <content>{"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"}</content>
    <link href="https://vulnerability.circl.lu/sighting/ce3a8f5b-fcfb-42cc-99f2-c4d00e64e5cd/export"/>
    <published>2024-08-21T09:52:15+00:00</published>
  </entry>
</feed>
