🇰🇷 한글 설명
Linux 커널의 vhost 구성 요소에서 VIRTIO_F_ACCESS_PLATFORM 설정 변경 시 IOTLB 전환 과정 중 이전 vring 접근 정보가 유효하게 유지되는 취약점이 발견되었습니다. 이로 인해 서로 다른 주소 공간에서 오래된 링 매핑이 사용될 수 있는 문제가 발생할 수 있습니다. 이를 해결하기 위해 VQ 뮤텍스를 순차적으로 획득하고 IOTLB 메타데이터를 무효화하는 로직이 추가되었습니다.
💡 쉬운 설명
가상화 기술을 사용할 때 메모리 주소를 관리하는 방식이 바뀌면, 예전 주소 정보가 남아 있어 데이터가 잘못된 곳을 참조할 수 있는 문제입니다. 이 취약점은 주소 체계가 바뀔 때 기존 정보를 깨끗이 지워줌으로써 데이터 혼선을 방지합니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
vhost: invalidate vring access on IOTLB transitions
When VIRTIO_F_ACCESS_PLATFORM changes, cached vring pointers and IOTLB
metadata are interpreted in a different address space. Keeping them
across the transition can leave stale ring mappings in use.
Clearing d->iotlb before taking the VQ locks also lets a worker observe
a transient NULL d->iotlb and fall back to d->umem while translating a
descriptor.
Add a common vhost_clear_device_iotlb() helper for vhost-net and
vhost-vsock. Take all VQ mutexes in index order before dropping the
device-wide IOTLB, invalidate each VQ's cached ring access and metadata,
clear pending IOTLB messages, and free the old table after the handoff.
This serializes the transition with workers and prevents mixed address
space mappings.
On the first direct-to-IOTLB transition, invalidate the cached vring
addresses. When an existing device IOTLB is replaced, preserve the
GIOVA ring addresses and reset only the metadata cache. After clearing
ACCESS_PLATFORM, userspace must configure the vring addresses for the
new address mode.
vhost_vq_invalidate_access() clears desc, avail, and used together.
Treat the VQ as invalidated only when all three are NULL, since a single
GIOVA address may legitimately be zero.
📍 영향받는 시스템
Linux Kernel (vhost-net 및 vhost-vsock 사용 환경)
⚔️ 공격 벡터
가상화 환경에서 VIRTIO_F_ACCESS_PLATFORM 설정을 변경하여 메모리 주소 공간 전환을 유도함으로써 잘못된 메모리 매핑을 이용할 수 있음
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 vhost 관련 IOTLB 무효화 로직을 적용해야 함
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 수정된 패치 버전 이후인지 확인하십시오.