https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Wed, 27 May 2026 17:22:32 +0000 https://vulnerability.circl.lu/sighting/92a7a835-fe95-47a0-b51c-35e0c76b7c4a/export {"uuid": "92a7a835-fe95-47a0-b51c-35e0c76b7c4a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39486", "type": "seen", "source": "https://t.me/cvedetector/141", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-39486 - In the Linux kernel, the following vulnerability h\", \n \"Content\": \"CVE ID : CVE-2024-39486 \nPublished : July 6, 2024, 10:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/drm_file: Fix pid refcounting race \n \n \nfilp->pid is supposed to be a refcounted pointer; however, before this \npatch, drm_file_update_pid() only increments the refcount of a struct \npid after storing a pointer to it in filp->pid and dropping the \ndev->filelist_mutex, making the following race possible: \n \nprocess A process B \n========= ========= \n begin drm_file_update_pid \n mutex_lock(&dev->filelist_mutex) \n rcu_replace_pointer(filp->pid, , 1) \n mutex_unlock(&dev->filelist_mutex) \nbegin drm_file_update_pid \nmutex_lock(&dev->filelist_mutex) \nrcu_replace_pointer(filp->pid, , 1) \nmutex_unlock(&dev->filelist_mutex) \nget_pid() \nsynchronize_rcu() \nput_pid() *** pid B reaches refcount 0 and is freed here *** \n get_pid() *** UAF *** \n synchronize_rcu() \n put_pid() \n \nAs far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y \nbecause it requires RCU to detect a quiescent state in code that is not \nexplicitly calling into the scheduler. \n \nThis race leads to use-after-free of a \"struct pid\". \nIt is probably somewhat hard to hit because process A has to pass \nthrough a synchronize_rcu() operation while process B is between \nmutex_unlock() and get_pid(). \n \nFix it by ensuring that by the time a pointer to the current task's pid \nis stored in the file, an extra reference to the pid has been taken. \n \nThis fix also removes the condition for synchronize_rcu(); I think \nthat optimization is unnecessary complexity, since in that case we \nwould usually have bailed out on the lockless check above. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"06 Jul 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-06T12:44:38.000000Z"} {"uuid": "92a7a835-fe95-47a0-b51c-35e0c76b7c4a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39486", "type": "seen", "source": "https://t.me/cvedetector/141", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-39486 - In the Linux kernel, the following vulnerability h\", \n \"Content\": \"CVE ID : CVE-2024-39486 \nPublished : July 6, 2024, 10:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/drm_file: Fix pid refcounting race \n \n \nfilp->pid is supposed to be a refcounted pointer; however, before this \npatch, drm_file_update_pid() only increments the refcount of a struct \npid after storing a pointer to it in filp->pid and dropping the \ndev->filelist_mutex, making the following race possible: \n \nprocess A process B \n========= ========= \n begin drm_file_update_pid \n mutex_lock(&dev->filelist_mutex) \n rcu_replace_pointer(filp->pid, , 1) \n mutex_unlock(&dev->filelist_mutex) \nbegin drm_file_update_pid \nmutex_lock(&dev->filelist_mutex) \nrcu_replace_pointer(filp->pid, , 1) \nmutex_unlock(&dev->filelist_mutex) \nget_pid() \nsynchronize_rcu() \nput_pid() *** pid B reaches refcount 0 and is freed here *** \n get_pid() *** UAF *** \n synchronize_rcu() \n put_pid() \n \nAs far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y \nbecause it requires RCU to detect a quiescent state in code that is not \nexplicitly calling into the scheduler. \n \nThis race leads to use-after-free of a \"struct pid\". \nIt is probably somewhat hard to hit because process A has to pass \nthrough a synchronize_rcu() operation while process B is between \nmutex_unlock() and get_pid(). \n \nFix it by ensuring that by the time a pointer to the current task's pid \nis stored in the file, an extra reference to the pid has been taken. \n \nThis fix also removes the condition for synchronize_rcu(); I think \nthat optimization is unnecessary complexity, since in that case we \nwould usually have bailed out on the lockless check above. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"06 Jul 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-06T12:44:38.000000Z"} https://vulnerability.circl.lu/sighting/92a7a835-fe95-47a0-b51c-35e0c76b7c4a/export Sat, 06 Jul 2024 12:44:38 +0000