CVE-2026-68093 in Linux
요약
\~에 의해 VulDB • 2026. 08. 10.
리눅스 커널에서 다음 취약점이 해결되었습니다:
KVM: SVM: 핫플러그 후 ASID 충돌을 피하기 위해 CPU 온라인 시 asid_generation 증가
가상 CPU(vCPU)가 스케줄 아웃(또는 차단)된 상태로 있다가, 해당 vCPU가 마지막으로 실행되었던 물리 CPU(pCPU)가 핫플러그 주기(온라인->오프라인->온라인)를 거친 후, 그 vCPU가 동일한 pCPU에서 다시 실행을 재개하면, 이제 다른 가상 CPU에 할당된 ASID로 인해 stale TLB 번역이 사용될 수 있습니다.
svm_enable_virtualization_cpu() 함수는 핫플러그 주기를 포함한 모든 CPU 온라인 이벤트마다 asid_generation을 1로 초기화하고 next_asid를 max_asid + 1로 설정합니다. next_asid가 풀 경계를 벗어나 시작하므로, 온라인 이벤트 이후 new_asid()의 첫 번째 호출은 항상 풀을 순환(wrap)하여 asid_generation을 2로 증가시키고 min_asid부터 ASID를 할당합니다.
다른 VM에 속한 두 vCPU(vCPU-A 및 vCPU-B), 그중 vCPU-A는 CPU-X에 고정되어 있으며 핫플러그 이벤트 전에 asid_generation=2와 ASID=N을 보유하고 있다고 가정해 봅시다:
1. CPU-X가 오프라인 되었다 다시 온라인으로 전환됨: asid_generation이 1로 초기화되고, next_asid = max_asid + 1입니다. 2. 하나 이상의 vCPU가 CPU-X로 마이그레이션되어 new_asid()를 호출하고 풀을 순환하며 min_asid부터 ASID를 소모합니다. 결국 다른 VM의 vCPU-B에 asid_generation=2 및 ASID=N이 할당됩니다 — 이는 핫플러그 전에 vCPU-A가 보유하고 있던 동일한 ASID입니다. 3. vCPU-A가 CPU-X에서 pre_svm_run() 진입: current_vmcb->cpu는 변경되지 않았으므로 마이그레이션 분기가 건너뜁니다. 저장된 asid_generation=2가 sd->asid_generation=2와 일치하므로 생성 확인이 조용히 통과하고, vCPU-A는 ASID=N으로 계속 실행됩니다 — 이는 방금 vCPU-B에 새로 할당된 동일한 ASID입니다.
서로 다른 VM의 두 vCPU가 이제 CPU-X에서 동일한 ASID로 실행되어 NPT TLB 엔트리를 공유하게 되고, 이로 인해 stale 번역이 생성됩니다.
이 충돌은 KVM 내부 오류(Suberror: 1, 에뮬레이션 실패)로 나타납니다. NPT 페이지 폴트는 VM의 물리 메모리 범위 훨씬 바깥에 있는 faulting GPA를 보고합니다 — 이는 stale TLB 번역이 사용되고 있다는 신호입니다. KVM은 명령어 에뮬레이션으로 후퇴하지만, 이 에뮬레이터가 구현하지 않은 FPU/XSave 명령(XRSTOR, STMXCSR)에서 실패합니다.
svm_enable_virtualization_cpu() 함수에서 asid_generation을 1로 초기화하는 대신 증가시킴으로써 이를 수정합니다. 모듈 로드 시 asid_generation은 0(memset)으로 시작하며, 이 증가는 1이 되어 이전 동작과 동일합니다. 이후의 핫플러그 주기에서는 생성 번호가 해당 CPU에서 vCPU가 이전에 관찰했던 어떤 값보다도 앞서게 되므로, pre_svm_run() 내의 생성 확인이 모든 핫플러그 주기 후 매번 새 vCPU에 대해 new_asid()를 신뢰할 수 있게 강제하게 됩니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.