From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E6E3B1F6674 for ; Mon, 21 Oct 2024 18:08:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729534110; cv=none; b=ipFWKj4MV3aTHVv3IQ5oCFRK5RGcwJzKGBxqP//dv5YHDc/1bnVRjsTRjo7agd/rK9i9FMc9wde+YdvL+cs7WxGcH2YFyVIW/FoyYlV+T0okDSDj5LQBlRVJz3HQSPTpGlDSEjUW3AgrzRNjo5RblQHE09kOm2kNj1qpAmD238g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729534110; c=relaxed/simple; bh=e+eLlJqv2ZszCopHXsdhc9XTgAP1utg46P/FO986VSA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ifjxB5Kat0Y454d+LvmUmQ6t/FcmGcdyHMdP1yXKD/OFfcGREcEdaiGt6NxKLyZF6NbdOO+fAue4C+Cb+Y4uaiYAmfFUDuaEEcaNO7vOmEpeMYEnsjGrhYfA3VqUm4PQrogKx8NO73CL0iseUSTLo6Y02HIcGUsyIHUhwE2Ym68= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=yoeq96t5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="yoeq96t5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60200C4CEC3; Mon, 21 Oct 2024 18:08:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1729534109; bh=e+eLlJqv2ZszCopHXsdhc9XTgAP1utg46P/FO986VSA=; h=From:To:Cc:Subject:Date:Reply-to:From; b=yoeq96t5QJ+XhoRDvsqMhxdjIxvTjaP4mw1nT8PVp85PW9x7sr0bPAsUuPSNJcQnQ /tzf1EUuZU2i8V1qgCeJ7KS+3BUIF3L5MIFxNat8BlTB/KmT6BNBnyX7vMm3L0E8Qf NyUGf64rP4tcMGe/VQYbJhu3Q/0SvS6Xtu1XW/Wc= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2024-49993: iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count Date: Mon, 21 Oct 2024 20:03:21 +0200 Message-ID: <2024102138-CVE-2024-49993-5b57@gregkh> X-Mailer: git-send-email 2.47.0 Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Reply-to: , X-Developer-Signature: v=1; a=openpgp-sha256; l=4950; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=e+eLlJqv2ZszCopHXsdhc9XTgAP1utg46P/FO986VSA=; b=owGbwMvMwCRo6H6F97bub03G02pJDOli05miZh7NsEo79n9F1nQPo/SajxOXFJ0Te/qXq+aPj bogt1hLRywLgyATg6yYIsuXbTxH91ccUvQytD0NM4eVCWQIAxenAExkag/DfI+Acgut3nelXJ/f af4NZ7b/oCd4hWHBNjHzhkd6q1p2136e7PytSJVb598XAA== X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit Description =========== 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). The Linux kernel CVE team has assigned CVE-2024-49993 to this issue. Affected and fixed versions =========================== Fixed in 5.10.227 with commit de9e7f687625 Fixed in 5.15.168 with commit 8840dc73ac9e Fixed in 6.1.113 with commit e03f00aa4a6c Fixed in 6.6.55 with commit dfdbc5ba10fb Fixed in 6.10.14 with commit 07e4e92f84b7 Fixed in 6.11.3 with commit 92ba5b014d54 Fixed in 6.12-rc1 with commit 3cf74230c139 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2024-49993 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/iommu/intel/dmar.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/de9e7f68762585f7532de8a06de9485bf39dbd38 https://git.kernel.org/stable/c/8840dc73ac9e1028291458ef1429ec3c2524ffec https://git.kernel.org/stable/c/e03f00aa4a6c0c49c17857a4048f586636abdc32 https://git.kernel.org/stable/c/dfdbc5ba10fb792c9d6d12ba8cb6e465f97365ed https://git.kernel.org/stable/c/07e4e92f84b7d3018b7064ef8d8438aeb54a2ca5 https://git.kernel.org/stable/c/92ba5b014d5435dd7a1ee02a2c7f2a0e8fe06c36 https://git.kernel.org/stable/c/3cf74230c139f208b7fb313ae0054386eee31a81