CVE-2024-49993

CVE Details

Release Date:2024-10-21

Description


In the Linux kernel, the following vulnerability has been resolved:\niommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count\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.\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.\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.\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.\nConsidered the following example timeline:\nT1T2\n========================================\nID1\nWD1\nwhile(WD1!=QI_DONE)\nunlock\nlock\nWD1=QI_DONE*WD2\nwhile(WD2!=QI_DONE)\nunlock\nlock\nWD1==QI_DONE?\nID1=QI_DONEWD2=DONE*\nreclaim()\nID1=FREE\nWD1=FREE\nWD2=FREE\nunlock\nsoft lockup! T2 never sees QI_DONE in WD2\nWhere:\nID = invalidation descriptor\nWD = wait descriptor\n* Written by hardware\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\nThe solution (in this patch) is state separation by using QI_FREE flag\nfor #1.\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).

See more information about CVE-2024-49993 from MITRE CVE dictionary and NIST NVD


NOTE: The following CVSS metrics and score provided are preliminary and subject to review.


CVSS v3 metrics

Base Score: 5.5
Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Version: 3.1
Attack Vector: Local
Attack Complexity: Low
Privileges Required: Low
User Interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: None
Availability: High

Errata information


PlatformErrataRelease Date
Oracle Linux version 8 (kernel-uek)ELSA-2024-128872024-12-18
Oracle Linux version 9 (kernel-uek)ELSA-2024-128872024-12-18


This page is generated automatically and has not been checked for errors or omissions. For clarification or corrections:

software.hardware.complete