Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

github логотип

GHSA-cjwf-5vh9-w48g

Опубликовано: 21 окт. 2024
Источник: github
Github: Не прошло ревью
CVSS3: 5.5

Описание

In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count

If qi_submit_sync() is invoked with 0 invalidation descriptors (for instance, for DMA draining purposes), we can run into a bug where a submitting thread fails to detect the completion of invalidation_wait. Subsequently, this led to a soft lockup. Currently, there is no impact by this bug on the existing users because no callers are submitting invalidations with 0 descriptors. This fix will enable future users (such as DMA drain) calling qi_submit_sync() with 0 count.

Suppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while concurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both threads then enter a while loop, waiting for their respective descriptors to complete. T1 detects its completion (i.e., T1's invalidation_wait status changes to QI_DONE by HW) and proceeds to call reclaim_free_desc() to reclaim all...

In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count

If qi_submit_sync() is invoked with 0 invalidation descriptors (for instance, for DMA draining purposes), we can run into a bug where a submitting thread fails to detect the completion of invalidation_wait. Subsequently, this led to a soft lockup. Currently, there is no impact by this bug on the existing users because no callers are submitting invalidations with 0 descriptors. This fix will enable future users (such as DMA drain) calling qi_submit_sync() with 0 count.

Suppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while concurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both threads then enter a while loop, waiting for their respective descriptors to complete. T1 detects its completion (i.e., T1's invalidation_wait status changes to QI_DONE by HW) and proceeds to call reclaim_free_desc() to reclaim all descriptors, potentially including adjacent ones of other threads that are also marked as QI_DONE.

During this time, while T2 is waiting to acquire the qi->q_lock, the IOMMU hardware may complete the invalidation for T2, setting its status to QI_DONE. However, if T1's execution of reclaim_free_desc() frees T2's invalidation_wait descriptor and changes its status to QI_FREE, T2 will not observe the QI_DONE status for its invalidation_wait and will indefinitely remain stuck.

This soft lockup does not occur when only non-zero descriptors are submitted.In such cases, invalidation descriptors are interspersed among wait descriptors with the status QI_IN_USE, acting as barriers. These barriers prevent the reclaim code from mistakenly freeing descriptors belonging to other submitters.

Considered the following example timeline: T1 T2

ID1 WD1 while(WD1!=QI_DONE) unlock lock WD1=QI_DONE* WD2 while(WD2!=QI_DONE) unlock lock WD1==QI_DONE? ID1=QI_DONE WD2=DONE* reclaim() ID1=FREE WD1=FREE WD2=FREE unlock soft lockup! T2 never sees QI_DONE in WD2

Where: ID = invalidation descriptor WD = wait descriptor

  • Written by hardware

The root of the problem is that the descriptor status QI_DONE flag is used for two conflicting purposes:

  1. signal a descriptor is ready for reclaim (to be freed)
  2. signal by the hardware that a wait descriptor is complete

The solution (in this patch) is state separation by using QI_FREE flag for #1.

Once a thread's invalidation descriptors are complete, their status would be set to QI_FREE. The reclaim_free_desc() function would then only free descriptors marked as QI_FREE instead of those marked as QI_DONE. This change ensures that T2 (from the previous example) will correctly observe the completion of its invalidation_wait (marked as QI_DONE).

5.5 Medium

CVSS3

Дефекты

CWE-667

Связанные уязвимости

CVSS3: 5.5
redhat
8 месяцев назад

[REJECTED CVE] A vulnerability has been identified in the Linux kernel's IOMMU (iommu/vt-d) subsystem, where calling qi_submit_sync() with zero invalidation descriptors could lead to a soft lockup due to misinterpreted descriptor statuses. An attacker with control over IOMMU operations could potentially trigger a deadlock, causing system instability.

nvd
8 месяцев назад

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

msrc
7 месяцев назад

Описание отсутствует

suse-cvrf
7 месяцев назад

Security update for the Linux Kernel

suse-cvrf
7 месяцев назад

Security update for the Linux Kernel

5.5 Medium

CVSS3

Дефекты

CWE-667