https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Mon, 11 May 2026 05:11:10 +0000 https://vulnerability.circl.lu/sighting/a4f2c5d8-13fc-4418-bd06-96511f0848f9/export {"uuid": "a4f2c5d8-13fc-4418-bd06-96511f0848f9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44956", "type": "seen", "source": "https://t.me/cvedetector/4839", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-44956 - \" Linux DRM Deadlock Vulnerability\"\", \n \"Content\": \"CVE ID : CVE-2024-44956 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/xe/preempt_fence: enlarge the fence critical section \n \nIt is really easy to introduce subtle deadlocks in \npreempt_fence_work_func() since we operate on single global ordered-wq \nfor signalling our preempt fences behind the scenes, so even though we \nsignal a particular fence, everything in the callback should be in the \nfence critical section, since blocking in the callback will prevent \nother published fences from signalling. If we enlarge the fence critical \nsection to cover the entire callback, then lockdep should be able to \nunderstand this better, and complain if we grab a sensitive lock like \nvm->lock, which is also held when waiting on preempt fences. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"04 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:17.000000Z"} {"uuid": "a4f2c5d8-13fc-4418-bd06-96511f0848f9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44956", "type": "seen", "source": "https://t.me/cvedetector/4839", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-44956 - \" Linux DRM Deadlock Vulnerability\"\", \n \"Content\": \"CVE ID : CVE-2024-44956 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/xe/preempt_fence: enlarge the fence critical section \n \nIt is really easy to introduce subtle deadlocks in \npreempt_fence_work_func() since we operate on single global ordered-wq \nfor signalling our preempt fences behind the scenes, so even though we \nsignal a particular fence, everything in the callback should be in the \nfence critical section, since blocking in the callback will prevent \nother published fences from signalling. If we enlarge the fence critical \nsection to cover the entire callback, then lockdep should be able to \nunderstand this better, and complain if we grab a sensitive lock like \nvm->lock, which is also held when waiting on preempt fences. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"04 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:17.000000Z"} https://vulnerability.circl.lu/sighting/a4f2c5d8-13fc-4418-bd06-96511f0848f9/export Wed, 04 Sep 2024 21:56:17 +0000