CVE-2026-74568 in Linux
요약
\~에 의해 VulDB • 2026. 08. 15.
리눅스 커널에서 다음 취약점이 해결되었습니다:
KVM: arm64: vgic: LPI 해제와 재등록 간 경쟁 조건(Race Condition) 수정
LPI의 참조 카운트 감소와 해당 구조체를 LPI xarray에서 제거하는 작업 간의 잠재적 경쟁 조건을 수정합니다.
LPI 구조체는 VGIC LPI xarray(dist->lpi_xa)에 유지됩니다. LPI 구조체의 참조 카운트가 0으로 떨어지면, vgic_release_lpi_locked()는 xarray 잠금(xarray lock) 하에서 해당 구조체를 xarray에서 제거하고 해제합니다.
그러나 참조 카운트 감소와 xarray에서의 구조체 제거가 단일 원자적 단계로 수행되지 않기 때문에, LPI 해제는 다른 CPU에서 동일한 INTID를 통해 vgic_add_lpi()에 의해 동시에 발생하는 LPI 재등록과 경쟁할 수 있습니다. 이는 예를 들어 게스트가 vCPU의 활성-대기 목록(ap_list)에서 여전히 참조되고 있는 동안 DISCARD 명령을 발행하고, 같은 INTID가 MAPTI를 통해 다시 매핑될 때 발생할 수 있습니다.
특히 vgic_release_lpi_locked()는 두 가지 서로 다른 경로에서 호출됩니다: vgic_put_irq()를 통한 직접 해제와 vgic_release_deleted_lpis()를 통한 지연 해제입니다. 직접 해제의 경우, 이 문제는 새로 등록된 LPI가 xarray에서 삭제되는 결과를 초래할 수 있습니다:
CPU0 (LPI 해제 중) CPU1 (새로운 LPI 추가 중) ==================== ===================== vgic_put_irq() __vgic_put_irq() refcount_dec_and_test() vgic_add_lpi() xa_lock_irqsave() old_irq = xa_load(.., intid) vgic_try_get_irq_ref(old_irq) == false 새 IRQ 삽입됨 --> __xa_store(.., intid, ..) xa_unlock_irqrestore() xa_lock_irqsave(); vgic_release_lpi_locked() __xa_erase(.., irq->intid) <-- 버그: 새로운 IRQ가 삭제됨 kfree_rcu(old_irq)
지연 해제 경로 동안에는 오래된 IRQ가 누출될 수 있습니다:
CPU0 (LPI 해제 중) CPU1 (새로운 LPI 추가 중) ==================== ===================== vgic_put_irq_norelease() __vgic_put_irq() refcount_dec_and_test() irq->pending_release = true vgic_add_lpi() xa_lock_irqsave() old_irq = xa_load(.., intid) vgic_try_get_irq_ref(oldirq) == false 버그: 오래된 IRQ 덮어씀 --> __xa_store(.., intid, ..) xa_unlock_irqrestore()
vgic_release_deleted_lpis() xa_lock_irqsave() xa_for_each() { .. } <-- pending_release = true인 오래된 IRQ가 이미 사라져서 해제할 수 없음
직접 해제 경로를 수정하기 위해 참조 카운트 감소를 xarray 잠금 내부로 이동하여, vgic_add_lpi()가 해제 대상이 되는 LPI를 절대 마주치지 않도록 보장합니다.
지연 해제 경로에서는 refcount 감소가 raw spinlock 하에서 발생해야 하므로 xarray 잠금을 획득할 수 없으며, 동일한 해결책은 작동하지 않습니다. 대신 vgic_add_lpi()를 업데이트하여, 만약 이 함수가 xarray에서 LPI를 제거한다면 해당 구조체를 해제하는 책임을 지도록 합니다. 결과적으로 지연 해제가 refcount를 감소시킨 후 LPI는 이제 동시에 해제될 수 있으므로, pending_release 필드에 접근하는 것은 Use-After-Free로부터 더 이상 안전하지 않습니다. 플래그의 모든 사용을 삭제하고, vgic_release_deleted_lpis()가 고아(LPI) 상태인 LPI들을 오직 참조 카운트만을 기반으로 식별하도록 업데이트합니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.