https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Thu, 28 May 2026 07:02:21 +0000 https://vulnerability.circl.lu/sighting/f26899b6-2786-4937-9369-9729b328df19/export {"uuid": "f26899b6-2786-4937-9369-9729b328df19", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49993", "type": "seen", "source": "https://t.me/cvedetector/8514", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-49993 - Intel VT-d IOMMU Lockup Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-49993 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \niommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count \n \nIf qi_submit_sync() is invoked with 0 invalidation descriptors (for \ninstance, for DMA draining purposes), we can run into a bug where a \nsubmitting thread fails to detect the completion of invalidation_wait. \nSubsequently, this led to a soft lockup. Currently, there is no impact \nby this bug on the existing users because no callers are submitting \ninvalidations with 0 descriptors. This fix will enable future users \n(such as DMA drain) calling qi_submit_sync() with 0 count. \n \nSuppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while \nconcurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both \nthreads then enter a while loop, waiting for their respective descriptors \nto complete. T1 detects its completion (i.e., T1's invalidation_wait status \nchanges to QI_DONE by HW) and proceeds to call reclaim_free_desc() to \nreclaim all descriptors, potentially including adjacent ones of other \nthreads that are also marked as QI_DONE. \n \nDuring this time, while T2 is waiting to acquire the qi->q_lock, the IOMMU \nhardware may complete the invalidation for T2, setting its status to \nQI_DONE. However, if T1's execution of reclaim_free_desc() frees T2's \ninvalidation_wait descriptor and changes its status to QI_FREE, T2 will \nnot observe the QI_DONE status for its invalidation_wait and will \nindefinitely remain stuck. \n \nThis soft lockup does not occur when only non-zero descriptors are \nsubmitted.In such cases, invalidation descriptors are interspersed among \nwait descriptors with the status QI_IN_USE, acting as barriers. These \nbarriers prevent the reclaim code from mistakenly freeing descriptors \nbelonging to other submitters. \n \nConsidered the following example timeline: \n T1 T2 \n======================================== \n ID1 \n WD1 \n while(WD1!=QI_DONE) \n unlock \n lock \n WD1=QI_DONE* WD2 \n while(WD2!=QI_DONE) \n unlock \n lock \n WD1==QI_DONE? \n ID1=QI_DONE WD2=DONE* \n reclaim() \n ID1=FREE \n WD1=FREE \n WD2=FREE \n unlock \n soft lockup! T2 never sees QI_DONE in WD2 \n \nWhere: \nID = invalidation descriptor \nWD = wait descriptor \n* Written by hardware \n \nThe root of the problem is that the descriptor status QI_DONE flag is used \nfor two conflicting purposes: \n1. signal a descriptor is ready for reclaim (to be freed) \n2. signal by the hardware that a wait descriptor is complete \n \nThe solution (in this patch) is state separation by using QI_FREE flag \nfor #1. \n \nOnce a thread's invalidation descriptors are complete, their status would \nbe set to QI_FREE. The reclaim_free_desc() function would then only \nfree descriptors marked as QI_FREE instead of those marked as \nQI_DONE. This change ensures that T2 (from the previous example) will \ncorrectly observe the completion of its invalidation_wait (marked as \nQI_DONE). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"21 Oct 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:02:02.000000Z"} {"uuid": "f26899b6-2786-4937-9369-9729b328df19", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49993", "type": "seen", "source": "https://t.me/cvedetector/8514", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-49993 - Intel VT-d IOMMU Lockup Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-49993 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \niommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count \n \nIf qi_submit_sync() is invoked with 0 invalidation descriptors (for \ninstance, for DMA draining purposes), we can run into a bug where a \nsubmitting thread fails to detect the completion of invalidation_wait. \nSubsequently, this led to a soft lockup. Currently, there is no impact \nby this bug on the existing users because no callers are submitting \ninvalidations with 0 descriptors. This fix will enable future users \n(such as DMA drain) calling qi_submit_sync() with 0 count. \n \nSuppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while \nconcurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both \nthreads then enter a while loop, waiting for their respective descriptors \nto complete. T1 detects its completion (i.e., T1's invalidation_wait status \nchanges to QI_DONE by HW) and proceeds to call reclaim_free_desc() to \nreclaim all descriptors, potentially including adjacent ones of other \nthreads that are also marked as QI_DONE. \n \nDuring this time, while T2 is waiting to acquire the qi->q_lock, the IOMMU \nhardware may complete the invalidation for T2, setting its status to \nQI_DONE. However, if T1's execution of reclaim_free_desc() frees T2's \ninvalidation_wait descriptor and changes its status to QI_FREE, T2 will \nnot observe the QI_DONE status for its invalidation_wait and will \nindefinitely remain stuck. \n \nThis soft lockup does not occur when only non-zero descriptors are \nsubmitted.In such cases, invalidation descriptors are interspersed among \nwait descriptors with the status QI_IN_USE, acting as barriers. These \nbarriers prevent the reclaim code from mistakenly freeing descriptors \nbelonging to other submitters. \n \nConsidered the following example timeline: \n T1 T2 \n======================================== \n ID1 \n WD1 \n while(WD1!=QI_DONE) \n unlock \n lock \n WD1=QI_DONE* WD2 \n while(WD2!=QI_DONE) \n unlock \n lock \n WD1==QI_DONE? \n ID1=QI_DONE WD2=DONE* \n reclaim() \n ID1=FREE \n WD1=FREE \n WD2=FREE \n unlock \n soft lockup! T2 never sees QI_DONE in WD2 \n \nWhere: \nID = invalidation descriptor \nWD = wait descriptor \n* Written by hardware \n \nThe root of the problem is that the descriptor status QI_DONE flag is used \nfor two conflicting purposes: \n1. signal a descriptor is ready for reclaim (to be freed) \n2. signal by the hardware that a wait descriptor is complete \n \nThe solution (in this patch) is state separation by using QI_FREE flag \nfor #1. \n \nOnce a thread's invalidation descriptors are complete, their status would \nbe set to QI_FREE. The reclaim_free_desc() function would then only \nfree descriptors marked as QI_FREE instead of those marked as \nQI_DONE. This change ensures that T2 (from the previous example) will \ncorrectly observe the completion of its invalidation_wait (marked as \nQI_DONE). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"21 Oct 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T21:02:02.000000Z"} https://vulnerability.circl.lu/sighting/f26899b6-2786-4937-9369-9729b328df19/export Mon, 21 Oct 2024 21:02:02 +0000 https://vulnerability.circl.lu/sighting/90d86819-f286-462c-8b20-5f0e524f01c0/export {"uuid": "90d86819-f286-462c-8b20-5f0e524f01c0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49993", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} {"uuid": "90d86819-f286-462c-8b20-5f0e524f01c0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49993", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} https://vulnerability.circl.lu/sighting/90d86819-f286-462c-8b20-5f0e524f01c0/export Thu, 14 Aug 2025 10:00:00 +0000