VsockDrop이 하이퍼바이저나 특권 없이 루트 권한을 획득하는 방법

요약

전체 버전으로 이동 ↓

5.5점으로 평가된 리눅스 커널 취약점에 대해, 권한이 없는 로컬 사용자를 루트 권한 사용자로 전환시키는 공개 익스플로잇이 등장했습니다. 이것이 바로 이번 주에 대응이 필요한 VsockDrop(CVE-2026-53365)의 핵심 사항입니다.

개요: VsockDrop은 리눅스 커널의 virtio vsock 제로카피(zerocopy) 전송 경로에 존재하는 결함인 CVE-2026-53365를 악용하는 로컬 권한 상승(LPE) 익스플로잇입니다. 대용량 MSG_ZEROCOPY가 여러 소켓 버퍼에 걸쳐 조각을 전송할 때, 릴리스 경로가 찾는 완료 객체(completion object)는 마지막 버퍼에만 포함됩니다. 그 이전의 모든 버퍼에는 고정된 사용자 페이지가 포함되어 있으며, 커널은 결국 한 번도 가져오지 않은 페이지 참조를 삭제해 버립니다.

잠재적 영향: 일반 비특권 계정에서 루트 권한을 획득합니다. 이 익스플로잇은 페이지 참조 횟수를 0으로 줄인 후, 여전히 고정된 해당 페이지를 /usr/bin/su의 페이지 캐시로 반환받아서, 그 안에 저장된 인터프리터 경로를 재작성한 뒤 su를 실행합니다. 이 공격 체인 어디에서도 정보 유출이나 커널 코드 실행이 발생하지 않는데, 이것이 이 공격이 이토록 일관되게 작동하는 주된 이유입니다.

중요도: 레드햇과 NVD는 모두 CVE-2026-53365에 대해 CVSS 기본 점수 5.5를 발표했으며, 가용성에 높은 영향을 미치지만 기밀성이나 무결성에는 영향을 미치지 않는 것으로 나타났고, 레드햇은 이를 ‘중간(Moderate)’ 수준으로 평가했습니다. 이 익스플로잇의 작성자는 7.8점을 주장합니다. 이 벡터는 업스트림 커밋 메시지에 기록된 리소스 회계 오류를 설명합니다. 그러나 동일한 누락된 완료 객체가 사용 중인 상태에서 해제된 페이지로 전환되는 io_uring 상호작용은 고려하지 않았습니다. 최종 점수 산정 결과가 어떻든 간에, 공개된 이 익스플로잇은 현재 발표된 5.5점 벡터가 포착하지 못한 기밀성 및 무결성상의 결과를 보여줍니다.

취약점에 노출된 대상: 우분투(Ubuntu)가 가장 시급한 주의가 필요한 대상입니다. 패치를 적용하지 않은 6.7 버전 이후의 리눅스 커널이 영향을 받으며, 이 취약점을 악용할 수 있는지 여부는 권한이 없는 프로세스가 io_uring 등록 버퍼를 제로카피(zerocopy)를 허용하는 vsock 전송 프로토콜과 함께 사용할 수 있는지에 달려 있습니다. 이 두 가지 요소는 우분투 24.04와 6.8 HWE 커널을 실행하는 우분투 22.04에서 기본적으로 활성화되어 있습니다. RHEL, AlmaLinux, Rocky 및 CloudLinux를 포함한 Enterprise Linux 9 및 10은 동일한 취약점 코드를 포함하고 있지만, kernel.io_uring_disabled가 2로 설정되어 있어 시연된 공격 체인을 차단합니다.

확인된 사항: 2026년 8월 18일, TuxCare는 Ubuntu 24.04에서 구성 변경 없이 첫 실행 시 비특권 계정에서 루트 셸을 재현했습니다. AlmaLinux 10.2에서는 동일한 익스플로잇이 기본 제공 상태에서 io_uring 초기화 단계에서 중단되었으나, io_uring을 명시적으로 다시 활성화한 후에는 루트 권한을 획득했습니다. io_uring을 다시 활성화한 상태에서 AlmaLinux 9.8을 대상으로 시도했을 때는 루트 권한에 도달하지 못했으나, 이는 완전한 실패(clean negative)와는 다릅니다.

지금 해야 할 일: 실행 중인 커널과 io_uring 정책을 확인한 다음, vsock이 로드되어 있는지 확인하십시오.

uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'

값이 2인 경우, 루트 사용자 포함 시스템 전체에서 io_uring 설정이 거부되며, 이는 취약한 코드를 제거하지 않고도 알려진 루트 악용 경로를 차단합니다. 값이 0인 경우 io_uring을 사용할 수 있으며, 이는 업스트림의 기본값이자 우분투가 제공하는 설정입니다. 세 번째 명령어의 출력 결과를 통해 vsock 관련 모듈이 로드되었음을 확인할 수 있습니다. 공개된 익스플로잇은 vsock_loopback과 VMADDR_CID_LOCAL을 사용할 수 있으므로 가상 머신이 필요하지 않습니다.

가능한 경우, 제공된 고정 버전의 커널을 적용하십시오. 데비안 13에는 해당 커널이 포함되어 있습니다. 반면 캐노니컬은 가장 중요한 두 가지 우분투 계열에 대해서는 아직 해당 커널을 제공하지 않았습니다. 즉시 재부팅이 불가능한 경우, KernelCare를 통해 버그가 수정된 커널을 적용하는 것이 일반적인 방법입니다. 또한 이 CVE에 대해서는 아직 재부팅 없이 적용 가능한 패치가 출시되지 않았으므로, 당분간은 아래의 완화 조치를 해당 시스템에 적용해야 합니다.

VsockDrop의 흥미로운 점은 또 다른 리눅스 커널 CVE가 존재한다는 사실이 아닙니다. CVE 기록에 기술된 내용과 실제 공개된 익스플로잇이 수행하는 행위 사이의 차이가 바로 그 흥미로운 점입니다.

CVE-2026-53365는 2026년 7월 13일에 공개되었는데, 이는 업스트림 수정 사항이 이미 5월 14일에 적용된 지 두 달이 지난 후였다. 공식 설명에는 제로카피 완료 추적 및 절대 해제되지 않는 고정 페이지에 대한 내용이 포함되어 있으며, 레드햇과 NVD 모두 이 취약점에 5.5점을 부여하고 가용성에만 영향을 미친다고 평가했다.

그러자 공개된 익스플로잇이 실제 상황을 바꿔놓았습니다. 이 익스플로잇은 동일한 참조 회계 결함이 io_uring으로 등록된 버퍼와 결합될 경우, 여전히 고정된 상태인 페이지를 해제하고, 이를 setuid 바이너리의 일부로 재할당함으로써 일반 로컬 사용자를 루트 권한 사용자로 전환한다는 사실을 보여주었습니다.

하나의 결함에 두 가지 결과가 따릅니다. CVE는 그 중 경미한 결과만 반영했습니다. 만약 취약점 보고서에 기재된 5.5 등급이 이 결함이 패치 목록에서 제외된 이유라면, 다시 목록에 포함되어야 합니다.

VsockDrop으로도 알려진 CVE-2026-53365는 정확히 무엇일까요?

VsockDrop은 리눅스 커널의 CVE-2026-53365에 대한 비특권 로컬 권한 상승 익스플로잇으로, 2026년 8월 Maher Azzouzi에 의해 공개되었으며, 그는 업스트림 수정 패치의 보고자로 기록되어 있습니다. 이 이름은 별도의 취약점을 가리키는 것이 아니라, 해당 익스플로잇과 기술 문서를 지칭합니다.

취약점이 있는 코드는 virtio vsock 제로카피 전송 경로에 위치해 있습니다. AF_VSOCK은 일반적으로 게스트와 하이퍼바이저 간의 통신과 관련이 있으므로, 이는 가상화 문제라고 자연스럽게 추측하기 쉽습니다. 하지만 그렇지 않습니다. 리눅스는 vsock_loopback 전송 방식을 통해 로컬 vsock 컨텍스트 ID인 VMADDR_CID_LOCAL(CID 1)을 노출하며, 개념 증명(PoC)은 해당 엔드포인트를 사용하여 동일한 시스템과 통신합니다. 일반 계정과 취약한 코드 사이에는 하이퍼바이저, 게스트, 사용자 네임스페이스, 능력(capability) 검사 등이 전혀 존재하지 않습니다.

따라서 필수 조건은 하이퍼바이저를 제어하는 것이 아닙니다. 필요한 기능이 지원되는 영향을 받은 커널 환경에서 일반 로컬 사용자로 바이너리를 실행할 수 있는 능력입니다. 공유 호스팅, 멀티테넌트 빌드 시스템, CI 러너 및 점프 호스트의 경우, 이는 해당 시스템에 있는 대부분의 계정에 해당합니다.

두 번째 핵심 요소는 io_uring입니다. 이 익스플로잇은 등록된 버퍼와 제로카피 전송을 함께 활용하며, 바로 이러한 상호작용을 통해 페이지 어카운팅 버그가 참조 언더플로우로 이어지고, 결국 루트 권한을 획득하게 됩니다.

시기도 중요합니다. 이 수정 프로그램은 2026년 5월 14일부터 공개되어 있었으며, 레드햇(Red Hat)의 스테파노 가르자렐라(Stefano Garzarella)가 작성한 것으로, 이 취약점을 악용하는 코드는 약 3개월 후에 등장했습니다. 누구도 갑작스러운 공격을 받은 것은 아니며, 이는 패치를 적용하지 않은 모든 커널이 공개된 수정 프로그램이 나온 지 무려 한 분기 동안이나 그대로 방치되어 있었다는 것을 의미합니다.

VsockDrop 루트 익스플로잇의 작동 원리

MSG_ZEROCOPY 전송은 페이로드를 복사하지 않습니다. 커널은 사용자 페이지를 고정하고, 해당 페이지에서 데이터를 전송한 뒤, 해당 페이지를 다시 안전하게 재사용할 수 있게 되면 오류 큐를 통해 사용자 공간에 알립니다. 이 모든 과정을 추적하는 객체가 ubuf_info이며, 보통 uarg라고 불립니다.

제로카피(zerocopy) 환경에서 vsock 전송 경로는 각 소켓 버퍼의 크기를 64 KiB로 제한하므로, 이보다 큰 데이터는 조각화됩니다. 수정 전에는 uarg가 루프의 마지막 버퍼에만 연결되었습니다. 그 이전의 버퍼들은 여전히 고정된 페이지를 포함하고 있었으나, 커널이 그곳에서 기대했던 완료 상태 정보는 전혀 포함되어 있지 않았습니다.

이것만으로도 CVE에서 설명하는 리소스 회계 문제가 발생합니다. 사용자 공간은 해당 페이지들이 비어 있다는 사실을 전혀 알지 못하며, send 루프가 조기에 중단될 경우 uarg는 아예 할당되지도 않습니다.

io_uring으로 등록된 버퍼의 경우 결과는 달라집니다. 해당 페이지들은 이미 장기 고정(long-term pinned) 상태이며, 네트워킹 스택은 해당 조각들을 관리 참조(managed references)로 표시하므로, 해제 경로에서는 이를 그대로 두어야 합니다. 이를 강제하는 가드(guard)는 버퍼에 uarg가 첨부되어 있는지 여부를 확인하는 검사 내부에 위치합니다. uarg가 없으면 검사가 실패하고, 가드는 호출되지 않으며, unref 루프는 참조를 받은 적이 없는 조각들에 대해 put_page()를 호출합니다. 그 결과, 매 송신 시마다 불필요한 페이지 참조 감소가 발생합니다.

일반적인 iovec을 통해 동일한 페이로드를 전송하면 이러한 현상이 전혀 발생하지 않습니다. 이 경우 io_uring이 적절한 참조를 확보하고, 계정이 균형을 이루며, 메모리 누수만 남게 됩니다. io_uring이 없으면 언더플로우도 발생하지 않습니다.

이 시점에서 계산 결과는 가혹합니다. 핀 바이어스는 1024로, 고정된 ABI 상수이므로, 알려진 횟수의 전송은 영향을 받는 모든 커널에서 알려진 양의 참조 카운트를 소모합니다. 버퍼를 등록하고, 매핑을 해제하며, 카운트가 0이 될 때까지 전송하면, 커널은 io_uring이 여전히 핀을 유지하고 있는 페이지를 해제합니다. /usr/bin/su의 콜드 페이지를 읽으면, 할당기는 해당 물리 페이지를 페이지 캐시로 바로 반환합니다. 이는 프리리스트가 후입선출(LIFO) 방식으로 관리되기 때문입니다. 여전히 등록된 버퍼는 이제 해당 페이지 캐시와 별칭 관계를 형성하게 되며, 고정된 쓰기 작업으로 ELF 인터프리터 경로가 재작성되고, su를 실행하면 커널은 이미 루트 권한이 적용된 공격자가 제공한 인터프리터를 로드하게 됩니다.

해당 체인에서는 커널 코드 실행이 발생하지 않습니다. 이는 루트 권한을 얻기 위한 순수 데이터 경로이며, 그 구조가 낯익게 느껴진다면 당연한 일입니다. 2026년 초에 발견된 ‘Copy Fail(CVE-2026-31431)’은 이와 유사한 기법을 사용하여, 기본 파일을 수정하지 않고도 setuid 바이너리의 페이지 캐시를 손상시켜 루트 권한을 획득했습니다. VsockDrop은 매우 다른 커널 버그를 통해 유사한 목표에 도달합니다.

이 공격을 테스트하는 모든 사용자에게 중요한 세부 사항이 하나 있습니다. 참조 드레인(reference drain)은 결정론적입니다. 반면 페이지 회수 단계는 확률론적이며, 실패한 시도는 동일한 부팅 세션 내에서 재시도할 수 없습니다. 따라서 이 익스플로잇은 ‘원샷(one-shot)’ 방식은 아니지만 신뢰할 수 있으며, 단 한 번의 실행 실패만으로는 커널이 영향을 받지 않는다는 증거가 될 수 없습니다.

VsockDrop에 대한 취약점이 확인되었나요?

네, 설정 변경 없이 문제가 발생한 Ubuntu 24.04 커널에서 발생합니다.

TuxCare는 2026년 8월 18일, 6.17 Azure 커널이 실행 중인 Ubuntu 24.04 환경에서 공개된 익스플로잇을 재현했습니다. 이 실행은 비특권 계정에서 시작되었으며, 별도의 조정이나 재구성 없이 첫 시도에서 바로 루트 셸을 확보했습니다. 유일한 부작용은 dmesg에 ‘BUG: Bad page state’ 항목이 기록된 것이었습니다. 해당 이미지에는 수정 사항이 포함되어 있지 않으며, Canonical도 이에 대한 수정 패치를 출시하지 않았습니다.

AlmaLinux 10.2의 반응은 완전히 달랐습니다. 익스플로잇은 ‘io_uring init failed’ 오류와 함께 즉시 중단되었는데, 이는 제공된 커널의 기본 설정인 `kernel.io_uring_disabled = 2`가 제대로 작동했기 때문입니다. 혹시 이 방에 계신 분들 중 SELinux가 이를 막았다고 가정하고 계신 분이 계시다면, SELinux가 원인이 아닙니다. AVC 거부 메시지는 나타나지 않았으며, SELinux가 허용 모드(permissive mode)로 설정된 상태에서도 실행은 여전히 실패했습니다. sysctl을 0으로 설정하자, 다음 시도에서는 루트 권한을 획득했으며, dmesg에는 오류가 없었고 oops도 발생하지 않았습니다.

“출하 시 문제 완화”는 “수정”과 같은 의미가 아닙니다.

AlmaLinux 9.8은 주의가 필요한 사례입니다. io_uring을 다시 활성화한 상태에서 익스플로잇이 처음부터 끝까지 실행되었으나, 루트 권한을 획득하지 못한 채 실패했습니다. 이는 명확한 부정 결과가 아닙니다. 언더플로우 발생에 필요한 모든 코드 전제 조건이 출시된 5.14 커널에 존재하며, 이 익스플로잇에 필요한 제로카피 전송 오퍼코드도 해당 커널 라인에 백포트되었고, 레드햇은 여전히 RHEL 9를 취약한 버전으로 분류하고 있습니다. 실패 시그니처는 이미 루트 권한을 획득한 호스트에서 발생한 알려진 실패 사례와 일치했습니다. 적절한 테스트를 통해 달리 확인될 때까지는 Enterprise Linux 9를 코드상 취약한 버전으로 간주해야 합니다.

실패한 실행 역시 흔적을 남기는데, 이는 생각보다 훨씬 유용합니다. 이 익스플로잇은 성공했을 때만 흔적을 지우기 때문에, 실패하면 /tmp/loader와 /var/tmp/.s 파일이 남게 되며, /var/tmp/.s 파일은 setuid root로 설정되어 있습니다. 이는 성공조차 하지 못한 시도로 인해 호스트에 남겨진 로컬 권한 상승 경로이며, 아무도 /var/tmp 디렉터리를 살펴보지 않습니다. 따라서 이 파일을 수동으로 삭제하십시오.

이 코드가 성공적으로 실행되면 재부팅 전까지 `su` 명령어가 중단되며, “실행할 수 없음: 필요한 파일을 찾을 수 없음” 오류가 발생합니다. 캐시를 지워도 소용이 없는데, 손상된 페이지가 여전히 참조를 유지하고 있기 때문에 재부팅해야만 정상으로 복구되기 때문입니다. 이는 간단한 탐지 신호일 뿐만 아니라 그 자체로 사용자에게 눈에 띄는 서비스 중단 현상입니다. 손상된 데이터는 페이지 캐시에 남아 있었으며, 이후 AlmaLinux에서 `rpm -V util-linux-core`를 실행했을 때 오류가 없었으므로 디스크상의 바이너리 파일은 손상되지 않은 상태였습니다. 복사-쓰기(Copy-on-Write) 파일 시스템에서는, 이 익스플로잇 작성자 본인의 경고에 따르면 이 결과가 적용되지 않을 수도 있습니다.

우분투 24.04는 VsockDrop 취약점에 노출되어 있나요?

네. 해당 Ubuntu 24.04 커널 버전은 취약하며, 공개된 루트 익스플로잇은 구성 변경 없이도 Ubuntu 24.04에서 재현되었습니다.

Canonical은 현재 CVE-2026-53365를 Noble 커널 패키지 전반에 걸쳐 취약점으로 분류하고 있으며, 여기에는 6.8 GA 라인과 6.17 HWE 라인은 물론 AWS, Azure, GCP 및 GKE 변형 버전도 포함됩니다. 6.8 HWE 커널을 실행하는 Ubuntu 22.04 역시 취약한 것으로 분류되어 있으며, 이 버전은 두 버전 중 설치 기반이 더 큰 편입니다.

우분투의 영향은 ‘영향을 받는 패키지 목록’에서 나타나는 것보다 더 크며, 이는 우분투의 기본 io_uring 구성이 이 취약점을 악용하기 위한 전제 조건을 그대로 남겨두기 때문입니다. 또한 캐노니컬은 이 CVE를 ‘중간’ 수준으로 평가하고 있어, 해당 코드줄에 대해 별도의 보안 공지가 발표되지 않은 것입니다.

최신 7.0 기반 커널은 별도로 개발 중입니다. Canonical은 현재 Ubuntu 26.04와 Ubuntu 24.04 HWE 7.0 계열 모두를 취약점이 있는 것으로 분류하고 있으며, 수정 작업이 진행 중이므로, 어느 쪽이든 문제가 해결되었다고 단정하기 전에 정확한 패키지 상태를 확인하시기 바랍니다.

어떤 리눅스 시스템이 영향을 받나요?

상류(upstream) 상황만 보면 간단합니다. 해당 동작을 도입한 vsock MSG_ZEROCOPY 관련 작업은 리눅스 6.7에 반영되었으며, 안정화된 수정 사항은 6.12.97, 6.18.34, 7.0.11 및 7.1에 포함되어 있습니다. 벤더들이 지속적으로 기능을 백포트하기 때문에, 배포판 커널의 경우 보안 권고 및 패키지별로 상황을 파악해야 합니다. RHEL 9는 5.14 기반 커널을 사용하고 있으며, 이는 버전 번호상 6.7보다 오래된 버전입니다. Red Hat은 해당 기능이 해당 커널 라인으로 백포트되었기 때문에, 여전히 RHEL 9와 RHEL 10을 취약한 버전으로 표시하고 있으며, 아직 수정 패치는 제공되지 않았습니다.

백포트는 취약점이 있는 기능과 수정 사항 모두를 업스트림 버전과 일치하지 않는 버전 번호로 이동시키므로, `uname -r`을 최종 판단 기준으로 삼지 말고, 조회할 식별자로만 간주하십시오.

Enterprise Linux 9 및 10을 보호하는 것은 패치가 아닌 바로 이 기본 설정이며, 이는 sysctl 파일로 제공되는 것이 아니라 커널에 직접 컴파일되어 있으므로, 해당 커널로 부팅되는 모든 시스템은 사용자 공간에서 나중에 변경하지 않는 한 이 설정을 그대로 상속받게 됩니다. 데이터베이스, 프록시 및 컨테이너 워크로드에서는 의도적으로 이 설정을 변경하기 때문에, 해당 호스트에서의 보안 취약성은 가설적인 것이 아니라 실제적인 문제가 됩니다.

VsockDrop을 완화하는 방법

시연된 체인은 io_uring으로 등록된 버퍼와 제로카피를 허용하는 vsock 전송 프로토콜이 필요합니다. 이 두 가지 전제 조건 중 하나라도 제거하면 작동이 중단되는데, 이는 대부분의 커널 버그가 초래하는 상황보다는 나은 편입니다. 두 가지 제어 방법 모두 커널 수정 사항을 대체할 수는 없습니다.

1. io_uring을 ‘denied’로 유지하십시오. Enterprise Linux 9 및 10에서는 값이 2인 것이 이미 기본 설정이므로, 이는 변경이 아닌 확인 단계에 해당합니다. 워크로드에서 실제로 io_uring이 필요한 경우가 아니라면 이 설정을 변경하지 마십시오.

우분투는 정반대의 경우입니다. 우분투에서 io_uring을 비활성화하면 데이터베이스, 프록시, 고처리량 스토리지 소프트웨어 등 실행 중인 애플리케이션이 의존할 수 있는 기능이 제거되므로, 이는 실질적인 운영상의 변경 사항이며 광범위한 영향을 미칠 수 있는 사안으로 간주해야 합니다. 또한 수정 패치가 출시되기 전까지 해당 시스템에서 사용할 수 있는 유일한 런타임 옵션이기도 합니다. 특정 서비스 하나에 io_uring이 필요한 경우, 값을 1로 설정하고 kernel.io_uring_group을 함께 사용하면 해당 그룹의 구성원에게만 이 기능을 허용할 수 있으며, 2 이외의 값은 완전히 비활성화된 것과 동일하게 해석되어서는 안 됩니다.

2. 필요하지 않은 곳에서는 vsock 전송 프로토콜을 제거하십시오. vsock을 사용하는 애플리케이션이 없는 베어 메탈 환경에서는 해당 모듈을 블랙리스트에 등록해도 대개 별다른 문제가 발생하지 않습니다.

lsmod | grep -E 'vsock|vmw_vsock'

그 자체로 게스트인 머신에는 무턱대고 적용하지 마십시오. QEMU 게스트 에이전트와 VMware Tools는 모두 vsock 전송 방식을 사용하며, 중첩 가상화 및 Firecracker 방식의 모든 환경도 마찬가지입니다. 이미 로드된 모듈의 경우, 블랙리스트가 효과를 발휘하려면 rmmod 명령을 실행하거나 재부팅해야 하므로, 이후 해당 모듈이 실제로 제거되었는지 확인하십시오.

두 제어 방법 모두 이 특정 악용 사례에 대해 테스트된 적이 없으므로, 검증된 무력화 수단이 아니라 필수적인 제거 조치로 간주하십시오.

VsockDrop 문제 해결 방법

업스트림 수정 사항은 커밋 ae38d9179190인 “vsock/virtio: 다중 SKB 전송에 대한 제로카피 완료 처리 수정”이며, 이는 TCP가 이미 수행하고 있는 방식을 따릅니다.

이 수정안은 전송 루프 도중에 uarg를 생성하여 마침내 마지막이 된 버퍼에 연결하는 대신, uarg를 미리 할당하고 각 버퍼에 대한 참조를 통해 모든 버퍼에 연결한 다음, 이후 초기 참조를 조정합니다. 각 작업이 완료될 때마다 카운트가 감소하며, 마지막 버퍼가 해제된 후에야 알림이 발생하고, 아무것도 전송하지 못한 채 실패한 전송은 uarg를 깔끔하게 종료합니다.

이렇게 하면 두 가지 문제점이 한 번에 해결됩니다. 이제 모든 버퍼가 uarg를 포함하므로, 릴리스 경로에서 관리되는 프래그먼트 가드가 원래 의도된 대로 참조되며, 더 이상 불필요한 참조로 인한 오류가 발생하지 않습니다. 백포트 작업은 각 벤더 커널이 메인라인에서 얼마나 멀어졌는지에 따라 달라집니다.

이 수정 사항은 업스트림 안정판 6.12.97, 6.18.34, 7.0.11 및 7.1에 포함되어 있습니다. 벤더 커널의 경우, 완전히 다른 버전 번호로 동일한 수정 사항이 적용될 수 있습니다.

CVE-2026-53365에 대한 재부팅 없이 적용 가능한 패치 현황

2026년 8월 18일 현재, KernelCare 팀은 영향을 받은 대부분의 배포판에 대해 재부팅 없이 적용 가능한 라이브 패치를 개발 중입니다. 첫 번째 패치는 48시간 이내에 배포될 것으로 예상됩니다.

패치가 적용되면, 다음 예정된 실행 시점에 적용되거나 요청 시 즉시 적용됩니다.

kcarectl --update

그런 다음 실행 중인 커널이 실제로 무엇을 포함하고 있는지 확인하십시오.

kcarectl --patch-info | grep 'CVE-2026-53365'

결과가 아무것도 반환되지 않는 경우, 이를 해당 기능이 지원되지 않는다는 의미나 누락으로 해석해서는 안 됩니다. 임시 완화 조치를 제거하기 전, 지원팀에 문의하여 정확한 커널 버전을 확인해야 하며, 제거한 후에 확인해서는 안 됩니다. 패치 빌드 타임스탬프는 신뢰도가 낮은 보조 지표일 뿐이며, 특정 CVE에 대한 증거로 간주되어서는 안 됩니다.

KernelCare가 재부팅 없이 중요한 커널 취약점을 어떻게 패치하는지 알아보세요 → 

VsockDrop에 대한 자주 묻는 질문

공격자가 CVE-2026-53365를 악용하려면 무엇이 필요할까요? io_uring이 사용 가능하고 vsock 전송 프로토콜을 로드할 수 있는 상태에서, 영향을 받는 커널 상에서 권한이 없는 로컬 사용자로 바이너리를 실행할 수 있는 능력입니다. 하이퍼바이저, 게스트, 사용자 네임스페이스, 특수 하드웨어는 필요하지 않습니다.

VsockDrop을 사용하려면 가상 머신이 필요한가요? 아닙니다. 바로 이 점이 대부분의 요약 글에서 잘못 설명되고 있는 부분입니다. vsock_loopback 전송 프로토콜을 사용하면 권한이 없는 프로세스도 로컬 CID를 통해 스스로와 통신할 수 있으므로, 가상화가 전혀 적용되지 않은 베어메탈 호스트에서도 여전히 사용할 수 있습니다.

RHEL 9와 RHEL 10도 VsockDrop의 영향을 받나요? 레드햇은 kernel-rt를 포함해 두 버전 모두를 취약한 것으로 분류했으나, 아직 수정 패치는 제공되지 않았습니다. 해당 커널들은 기본적으로 io_uring을 차단하기 때문에 공개된 익스플로잇 코드는 제공된 상태 그대로는 실행되지 않으며, 이 취약점은 해당 기본 설정이 변경된 경우에만 드러납니다.

CVE-2026-53365는 원격으로 악용될 수 있습니까? 아닙니다. 로컬 계정이 필요합니다. 따라서 공유 호스팅, 멀티테넌트 빌드 시스템, CI 러너, 그리고 애플리케이션 사용자가 바이너리를 실행할 수 있는 모든 호스트가 여전히 해당 범위에 포함됩니다.

누군가 이를 시도했는지 어떻게 알 수 있을까요? 실패한 시도가 남기는 setuid root 바이너리인 /var/tmp/.s와 /tmp/loader를 확인해 보세요. 필수 파일이 없다는 오류 메시지를 표시하는 su 오류와 dmesg에 나타나는 “BUG: Bad page state” 메시지가 함께 나타난다면, 해당 부팅 시 실행이 성공했음을 시사합니다.

CVE-2026-53365에 대한 패치가 있나요? 업스트림 수정 사항은 6.12.97, 6.18.34, 7.0.11 및 7.1에 포함되어 있으며, 데비안(Debian)은 trixie 및 bookworm 6.12 커널에 대한 수정 사항을 배포했습니다. 캐노니컬(Canonical)은 해당 Ubuntu 계열에 대한 수정 사항을 배포하지 않았으며, 이 글을 작성하는 시점까지 이 CVE에 대한 재부팅 없이 적용 가능한 패치는 출시되지 않았습니다.

VsockDrop 연표

참조

• Maher Azzouzi, VsockDrop 개념 증명 및 기술 보고서, https://github.com/MaherAzzouzi/vsockdrop
• 리눅스 업스트림 수정 사항 ae38d9179190, “vsock/virtio: 멀티 SKB 전송에 대한 제로카피 완료 처리 수정”, https://git.kernel.org/linus/ae38d9179190a956e2a87a69ef1dd6f451b51c4d
• Linux 6.7에 해당 코드가 도입된 커밋 581512a6dc93, “vsock/virtio: MSG_ZEROCOPY 플래그 지원”
• 이 결함을 드러낸 검토가 이루어진 고정 페이지 계수 수정 사항인 커밋 1cb36e252211
• Red Hat CVE-2026-53365, https://access.redhat.com/security/cve/cve-2026-53365
• NVD CVE-2026-53365, https://nvd.nist.gov/vuln/detail/CVE-2026-53365
• Ubuntu CVE-2026-53365, https://ubuntu.com/security/CVE-2026-53365
• 데비안 CVE-2026-53365, https://security-tracker.debian.org/tracker/CVE-2026-53365