CVE-2024-49993

{"id": "CVE-2024-49993", "cveTags": [], "metrics": {}, "published": "2024-10-21T18:15:19.477", "references": [{"url": "https://git.kernel.org/stable/c/07e4e92f84b7d3018b7064ef8d8438aeb54a2ca5", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/3cf74230c139f208b7fb313ae0054386eee31a81", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/8840dc73ac9e1028291458ef1429ec3c2524ffec", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/92ba5b014d5435dd7a1ee02a2c7f2a0e8fe06c36", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/de9e7f68762585f7532de8a06de9485bf39dbd38", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/dfdbc5ba10fb792c9d6d12ba8cb6e465f97365ed", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e03f00aa4a6c0c49c17857a4048f586636abdc32", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "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\tT1\t\t\tT2\n========================================\n\tID1\n\tWD1\n\twhile(WD1!=QI_DONE)\n\tunlock\n\t\t\t\tlock\n\tWD1=QI_DONE*\t\tWD2\n\t\t\t\twhile(WD2!=QI_DONE)\n\t\t\t\tunlock\n\tlock\n\tWD1==QI_DONE?\n\tID1=QI_DONE\t\tWD2=DONE*\n\treclaim()\n\tID1=FREE\n\tWD1=FREE\n\tWD2=FREE\n\tunlock\n\t\t\t\tsoft 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)."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige el bloqueo potencial si se llama a qi_submit_sync con un recuento de 0 Si se invoca qi_submit_sync() con 0 descriptores de invalidaci\u00f3n (por ejemplo, para fines de vaciado de DMA), podemos encontrarnos con un error en el que un hilo de env\u00edo no detecta la finalizaci\u00f3n de invalidation_wait. Posteriormente, esto condujo a un bloqueo suave. Actualmente, este error no tiene impacto en los usuarios existentes porque ning\u00fan llamante est\u00e1 enviando invalidaciones con 0 descriptores. Esta correcci\u00f3n permitir\u00e1 a los futuros usuarios (como DMA drain) llamar a qi_submit_sync() con un recuento de 0. Supongamos que el hilo T1 invoca qi_submit_sync() con descriptores distintos de cero, mientras que, al mismo tiempo, el hilo T2 llama a qi_submit_sync() con cero descriptores. Ambos hilos entran entonces en un bucle while, esperando a que se completen sus respectivos descriptores. T1 detecta su finalizaci\u00f3n (es decir, el estado invalidation_wait de T1 cambia a QI_DONE por HW) y procede a llamar a reclaim_free_desc() para recuperar todos los descriptores, incluyendo potencialmente los adyacentes de otros subprocesos que tambi\u00e9n est\u00e1n marcados como QI_DONE. Durante este tiempo, mientras T2 espera adquirir el qi->q_lock, el hardware IOMMU puede completar la invalidaci\u00f3n para T2, estableciendo su estado en QI_DONE. Sin embargo, si la ejecuci\u00f3n de reclaim_free_desc() por parte de T1 libera el descriptor invalidation_wait de T2 y cambia su estado a QI_FREE, T2 no observar\u00e1 el estado QI_DONE para su invalidation_wait y permanecer\u00e1 bloqueado indefinidamente. Este bloqueo suave no ocurre cuando solo se env\u00edan descriptores distintos de cero. En tales casos, los descriptores de invalidaci\u00f3n se intercalan entre los descriptores de espera con el estado QI_IN_USE, actuando como barreras. Estas barreras evitan que el c\u00f3digo de recuperaci\u00f3n libere por error descriptores que pertenecen a otros remitentes. Considere la siguiente l\u00ednea de tiempo de ejemplo: 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 nunca ve QI_DONE en WD2 Donde: ID = descriptor de invalidaci\u00f3n WD = descriptor de espera * Escrito por hardware La ra\u00edz del problema es que el indicador de estado del descriptor QI_DONE se usa para dos prop\u00f3sitos conflictivos: 1. se\u00f1alar que un descriptor est\u00e1 listo para ser recuperado (para ser liberado) 2. se\u00f1alar por el hardware que un descriptor de espera est\u00e1 completo La soluci\u00f3n (en este parche) es la separaci\u00f3n de estados mediante el uso del indicador QI_FREE para #1. Una vez que los descriptores de invalidaci\u00f3n de un hilo est\u00e1n completos, su estado se establecer\u00eda en QI_FREE. La funci\u00f3n reclaim_free_desc() solo liberar\u00eda los descriptores marcados como QI_FREE en lugar de los marcados como QI_DONE. Este cambio asegura que T2 (del ejemplo anterior) observar\u00e1 correctamente la finalizaci\u00f3n de su invalidation_wait (marcada como QI_DONE)."}], "lastModified": "2024-10-23T15:13:25.583", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}