# Báo Động Đỏ Cho Hạ Tầng Ảo Hóa: Lỗ Hổng Januscape Cho Phép Kẻ Tấn Công Chiếm Quyền Host Từ Guest VM. ## Tóm Tắt Rủi Ro CVE-2026-53359, được đặt tên là **Januscape**, là lỗ hổng use-after-free trong subsystem shadow MMU của Linux KVM/x86. Lỗ hổng cho phép một máy ảo (guest) thực hiện hai hành động có mức độ tác động khác nhau lên máy chủ vật lý (host): gây crash toàn bộ host kernel (và kéo theo mọi VM khác trên cùng máy vật lý), hoặc — theo nghiên cứu chưa được công bố đầy đủ — thực thi mã tùy ý với quyền root trên host. Bug tồn tại từ tháng 8/2010 và ảnh hưởng đến mọi kernel x86 Linux chạy KVM với nested virtualization từ đó đến nay — khoảng 16 năm. ARM64 không bị ảnh hưởng. Lỗ hổng yêu cầu kẻ tấn công có quyền root bên trong guest VM — điều kiện thông thường ở bất kỳ cloud instance nào được thuê. Đây là vấn đề nghiêm trọng với các nhà cung cấp dịch vụ cloud x86 (bao gồm cả các hệ thống private cloud nội địa), đặc biệt khi nested virtualization được bật để phục vụ khách hàng cần chạy VM lồng nhau. ## Bối Cảnh Kỹ Thuật

Tiêu chí

Thông tin chi tiết (Lỗ hổng Januscape)

CVE

CVE-2026-53359

Sản phẩm

Module ảo hóa KVM (Kernel-based Virtual Machine) trong nhân hệ điều hành Linux (tồn tại từ tháng 8/2010, hỗ trợ cả CPU Intel và AMD).

CWE

CWE-416 (Use-After-Free - Sử dụng bộ nhớ sau khi giải phóng).

CVSS 3.1

Mức độ: Critical/High (Rất nghiêm trọng)

Ước tính Vector (dựa trên tính chất Guest-to-Host): AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Điều kiện

1. Máy chủ vật lý (Host) cho phép/kích hoạt tính năng ảo hóa lồng nhau (Nested Virtualization).

2. Kẻ tấn công phải chiếm được đặc quyền cao nhất (root) bên trong máy ảo khách (Guest VM).

Khai thác

Guest-to-Host Escape: Thoát khỏi máy ảo để thực thi mã tùy ý (RCE) trên máy chủ vật lý với quyền root; Gây sập toàn bộ máy chủ (Host Kernel Panic / DoS); Leo thang đặc quyền cục bộ (LPE).

Phát hiện bởi

Nhà nghiên cứu bảo mật Hyunwoo Kim (bí danh @v4bel).

## Phạm Vi Ảnh Hưởng * **Vulnerable từ:** commit `2032a93d66fa` — 01/08/2010 (Linux 2.6.36 era) * **Fixed tại:** commit `81ccda30b4e8` — 16/06/2026 (merge mainline) * **Kiến trúc bị ảnh hưởng:** Intel x86, AMD x86 * **Kiến trúc không bị ảnh hưởng:** ARM64 **Stable kernel versions đã được patch (phát hành 04/07/2026):** | **Stable branch** | **Phiên bản fixed** | | --- | --- | | v7.x | 7.1.3 | | v6.18.x | 6.18.38 | | v6.12.x | 6.12.95 | | v6.6.x | 6.6.144 | | v6.1.x | 6.1.177 | | v5.15.x | 5.15.211 | | v5.10.x | 5.10.260 | **Điều kiện khai thác:** * Kẻ tấn công có **quyền root bên trong guest VM** (thỏa mãn trên mọi cloud instance thông thường). * **Nested virtualization được bật** trên host (`kvm_intel.nested=1` hoặc `kvm_amd.nested=1`). * Không yêu cầu sự hợp tác từ QEMU hay bất kỳ userspace VMM nào. * Không yêu cầu tương tác từ người dùng khác. **Attack vector:** Local (Guest) → Host Kernel — không phải remote over network. ## **Giới Thiệu Về Linux KVM/x86** Để hiểu Januscape, chúng ta sẽ cần nắm rõ ba lớp kỹ thuật: **KVM hoạt động như thế nào**, **KVM quản lý bộ nhớ ra sao**, và **nested virtualization thay đổi mọi thứ thế nào**. Mỗi lớp là điều kiện cần để lỗ hổng tồn tại. ### **KVM là gì** **KVM (Kernel-based Virtual Machine)** là công nghệ ảo hóa được tích hợp thẳng vào Linux kernel từ năm 2007. Thay vì chạy như một phần mềm riêng biệt, KVM biến Linux thành hypervisor — kernel vừa điều hành máy thật, vừa quản lý các máy ảo chạy trên nó. Kiến trúc thực tế gồm hai phần phối hợp: * **KVM (kernel module):** xử lý CPU và bộ nhớ của guest — phần nhạy cảm, chạy trong kernel space * **QEMU (userspace):** giả lập thiết bị như disk, card mạng — phần ít đặc quyền hơn Januscape nằm hoàn toàn trong phần KVM kernel. QEMU không liên quan. ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/89141308-9a8d-4375-a969-71db5c4bce57.png align="center") ### **Vấn đề bộ nhớ — Tại sao không đơn giản?** Guest VM nghĩ nó sở hữu toàn bộ RAM từ địa chỉ 0. Thực tế "RAM" đó chỉ là một vùng memory của host mà KVM cấp phát. KVM phải liên tục dịch: địa chỉ mà guest dùng → địa chỉ vật lý thực sự trên phần cứng. ```plaintext Địa chỉ guest (GPA) → [KVM dịch] → Địa chỉ vật lý thực (HPA) ``` CPU hiện đại (Intel từ 2008, AMD từ 2008) có phần cứng làm việc này tự động — gọi là **EPT** (Intel) hoặc **NPT** (AMD). KVM dùng EPT/NPT theo mặc định và hoạt động hiệu quả. **Shadow paging** là giải pháp cũ hơn, do phần mềm KVM tự xử lý thay vì phần cứng. Nó chậm hơn và phức tạp hơn — nhưng vẫn còn trong codebase và vẫn được kích hoạt trong một tình huống quan trọng. ### **Nested Virtualization — Điều kiện trigger của Januscape** **Nested virtualization** là khả năng chạy hypervisor bên trong VM. Ví dụ thực tế: bạn thuê một VM trên AWS, rồi chạy VMware ESXi hoặc KVM bên trong VM đó để tạo thêm VM con. Máy vật lý → Host KVM (L0) └→ VM của bạn (L1) — guest có nested virt └→ VM con bên trong VM (L2) Tính năng này rất phổ biến trong cloud: Kubernetes với VM worker nodes, môi trường test hypervisor, hay cloud-in-cloud. Vấn đề nằm ở đây: khi L1 guest chạy hypervisor và cần quản lý bộ nhớ cho L2 guest của nó, host KVM **không thể dùng EPT/NPT đơn giản nữa** — nó phải kích hoạt lại shadow paging để xử lý bộ nhớ cho lớp lồng nhau này. | **Cấu hình** | **Cơ chế bộ nhớ** | **Januscape có khai thác được?** | | --- | --- | --- | | KVM thông thường (không nested) | EPT/NPT (hardware) | Không | | KVM với nested virtualization bật | Shadow paging (software) | Có | Shadow paging đã tồn tại 16 năm với một lỗi nhỏ trong cách nó định danh và tái sử dụng các "trang bóng" (shadow page) — đó chính xác là điều Januscape khai thác. ## **Cơ Chế Khai Thác** ### **Root Cause** KVM/x86 triển khai **shadow paging** — một cơ chế duy trì bộ page table riêng (shadow page table) để ánh xạ virtual address của guest sang physical address của host, dùng khi hardware EPT/NPT không hoạt động hoặc khi nested virtualization buộc KVM đi qua đường code legacy. Mỗi shadow page được đặc trưng bởi hai thuộc tính: * **GFN (Guest Frame Number):** địa chỉ bộ nhớ guest mà shadow page quản lý * **Role:** kiểu của shadow page — bao gồm `direct` (ánh xạ trực tiếp, dùng cho large page 2MB) và `indirect` (ánh xạ qua page directory, dùng cho 4KB page) Hàm `kvm_mmu_get_child_sp()` có nhiệm vụ tìm hoặc tạo shadow page con. Lỗ hổng nằm ở đây: hàm này chỉ so sánh GFN mà bỏ qua `role.word` khi quyết định reuse một shadow page cũ. ### Tình huống khai thác cụ thể 1. Guest tạo một PDE (Page Directory Entry) trỏ tới large 2MB page → KVM cấp shadow page với `direct=1` 2. Guest thay đổi PDE đó để trỏ sang non-leaf page (4KB) → KVM cần shadow page với `direct=0` 3. `kvm_mmu_get_child_sp()` tìm thấy shadow page cũ có GFN khớp, **reuse** nó mà không kiểm tra role 4. KVM cài đặt leaf SPTE (4KB) trên shadow page có `direct=1` — record rmap entry theo GFN tính từ `sp->gfn + index` thay vì `sp->shadowed_translation[]` 5. Khi shadow page bị xóa, `rmap_remove()` tính GFN sai → **không xóa được rmap entry** → dangling pointer 6. Khi memslot bị drop, shadow page được giải phóng nhưng rmap entry vẫn tồn tại 7. Code sau đó (dirty logging, MMU notifier invalidation...) dereference SPTE trong freed page → **use-after-free** ### **Hai impact song song** **Impact 1 — Host DoS (PoC đã public):** Trong hầu hết trường hợp, kernel phát hiện corruption và tự kill bằng BUG/panic. Đây là điều PoC của Kim khai thác: race condition chạy trong guest khiến host panic sau vài giây đến vài phút. `[*] poc step 4/4: race live -- host DoS triggering ...` `kernel BUG at arch/x86/kvm/mmu/mmu.c (pte_list_remove)` `Comm: qemu-kvm` **Impact 2 — Full Host RCE (exploit chưa public):** Trong trường hợp hiếm hơn, freed page được allocator cấp lại cho mục đích khác trước khi cleanup chạy. Cleanup sau đó ghi một giá trị vào vùng nhớ không còn thuộc về nó nữa — kẻ tấn công kiểm soát được **địa chỉ đích của write**. Từ primitive "write-what-where" hạn chế này, Kim khẳng định đã xây dựng thành công full escape trong controlled environment. Chi tiết exploit path cho Intel và AMD có thể khác nhau ở bước cuối. ### **Sử dụng trong kvmCTF** Januscape đã được Kim dùng như một **0-day submission** trong Google kvmCTF — chương trình bug bounty kiểm soát của Google dành cho KVM, với mức thưởng tối đa $250,000 cho full guest-to-host escape. Đây là bằng chứng exploit hoàn chỉnh tồn tại và đã được xác minh trong môi trường có kiểm soát. ## Phân Tích PoC **Mục đích phần này:** Phân tích kỹ thuật `poc.c` để hiểu cách lỗ hổng được kích hoạt trong thực tế — không nhằm hướng dẫn tấn công. PoC chỉ trigger DoS path (host kernel panic); full escape exploit không được release. ### **Kiến trúc tổng quan** ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/728b87f0-f626-4dc1-a391-63cb173c0f17.png align="center") PoC hỗ trợ **dual-arch** — cùng một codebase, hai backend virtualization: * **Intel** (mặc định): dùng VMX instruction set (`vmxon`, `vmwrite`, `vmlaunch`) * **AMD** (`amd=1`): dùng SVM/VMCB (`vmrun`, VMCB struct) Cả hai path đều đổ vào cùng một lỗi trong host KVM shadow MMU. ### **Các tham số module và ý nghĩa**

Tên biến

Kiểu dữ liệu

Giá trị

Ý nghĩa / Mô tả

amd

static int

0

Định tuyến kiến trúc ảo hóa: 0 cho Intel VMX, 1 cho AMD SVM.

nvcpu

static int

8

Số lượng thread vCPU tham gia vào quá trình tạo race condition.

dwell

static int

256

Thời gian nghỉ (tính bằng microgiây - µs) của thread WRITER trong mỗi vòng lặp.

run_ms

static int

600000

Thời gian sống tối đa (timeout) của toàn bộ PoC (600.000 ms = 10 phút).

diag

static int

1

Cờ (flag) cho phép in log chẩn đoán lỗi ra màn hình (1 = Bật).

nflood

static int

0

Số lượng thread "flood" được sinh thêm để tăng cường áp lực (tải) lên hệ thống.

`nvcpu = 8` là quan trọng nhất — càng nhiều vCPU cùng tham gia race, xác suất hit window timing càng cao. Trên máy nhiều core, PoC thường panic host trong **vài giây đến vài phút**. ### **Bước 1 — Setup nested VM với page table kiểm soát** PoC cấp phát một tập page vật lý và xây dựng bộ page table hoàn chỉnh cho L2 guest: ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/bd68cb42-90e0-47bb-a31a-ee4f139ee101.png align="center") Page directory (PD) của L2 được cấu trúc cẩn thận để địa chỉ `GVA_PRIME` ban đầu trỏ đến một **2MB large page** (PDE với bit PS=1). Đây là điều kiện để host KVM tạo shadow page với `direct=1` tại PDE slot đó. ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/9440b2ae-dae8-4726-adcd-ad499366fd11.png align="center") Sau đó PoC cho L2 chạy và thực hiện page walk qua địa chỉ `GVA_PRIME` — host KVM sẽ fetch shadow page cho PDE slot này, tạo `kvm_mmu_page` với `role.direct=1`, `gfn=ptg_pa>>12`. ### **Bước 2 — Hàm next\_grip(): Logic toggle tạo race condition** Đây là hàm trung tâm của race condition: ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/5d68e159-dfe6-4fde-a2a3-cb98509c1127.png align="center") `next_grip()` giao thức hoá việc **toggle PDE liên tục** giữa hai trạng thái: | **Lần gọi** | **Giá trị PDE** | **Shadow page cần** | [`role.direct`](http://role.direct) | | --- | --- | --- | --- | | Lần 1, 9, 17… (mod 8 = 0) | Large 2MB (PS=1) | `direct=1` | 1 | | Lần 2–8, 10–16… | Small 4KB table | `direct=0` | 0 | Mục tiêu: trong khi **WRITER thread** đang toggle PDE từ large → small (cần `direct=0`), **FAULT thread** trigger page fault buộc host KVM chạy `kvm_mmu_get_child_sp()`. Nếu timing đúng, KVM tìm thấy shadow page cũ có `gfn` khớp (của lần large page trước) nhưng [`role.direct`](http://role.direct)`=1` — và do bug, nó **reuse shadow page sai role** thay vì tạo mới. ### **Bước 3 — WRITER thread và FAULT thread phối hợp** PoC spawn hai loại thread theo vai trò (role): ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/2c42354b-0eb3-4488-803b-e891421803fb.png align="center") **WRITER thread** chạy vòng lặp tight: ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/2220e03b-1def-44d3-b94a-2169b863fbcf.png align="center") **FAULT thread** trigger page fault tại `GVA_PRIME` trong L2: ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/6de1640c-2dda-4fb7-a198-62caf4de732e.png align="center") Race window là khoảng thời gian giữa lúc WRITER ghi PDE mới (cần `direct=0`) và lúc host KVM invalidate shadow page cũ (`direct=1`). Trong window này, FAULT thread kích hoạt fetch path — KVM nhìn thấy GFN khớp, bỏ qua role, reuse shadow page sai. ### **Bước 4 — Từ role mismatch đến kernel panic** Sau khi reuse xảy ra, host KVM cài đặt leaf SPTE (4KB) vào shadow page có `direct=1`. Khi tính GFN để đăng ký vào rmap: ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/67c89fa6-829f-4881-88f4-6c27c89be03d.png align="center") Rmap entry được đăng ký với **GFN thực của guest** (đúng). Nhưng khi rmap remove, nó tính GFN bằng `sp->gfn + index` (sai vì đây là direct page). Hai GFN không khớp → `pte_list_remove()` không tìm được entry → kích hoạt BUG\_ON: ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/9b1f0449-ae33-4844-970f-99757d7d9210.png align="center") Host kernel tự kill bằng `BUG()` — điều này kéo theo **toàn bộ VM** trên cùng physical host bị shutdown, vì host kernel không còn hoạt động nữa. ### **Tại sao Intel và AMD đều bị — nhưng code khác nhau** Bug nằm trong **host KVM shadow MMU** — code dùng chung cho cả Intel lẫn AMD. Sự khác biệt chỉ ở tầng **guest L1 hypervisor setup** trong PoC: ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/1bfc657a-7c91-477e-86e1-1d9899cffef6.png align="center") Điều này giải thích tại sao Januscape là KVM escape đầu tiên **triggerable trên cả Intel lẫn AMD** — không phải vì Kim viết hai exploit riêng, mà vì lỗi nằm ở tầng abstraction chung phía trên cả hai. ## **Ghi nhận khai thác** **Trạng thái:** PoC public, full exploit chưa public, chưa ghi nhận in-the-wild exploitation ngoài kvmCTF. **CISA SSVC assessment (07/07/2026):** ![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/28d26dd3-c3be-4505-893d-1492e09c0caa.png align="center") `technicalImpact: total` phản ánh rằng nếu full exploit được dùng thành công, kẻ tấn công kiểm soát hoàn toàn host — bao gồm tất cả guest VM khác trên cùng máy vật lý. ### **Timeline sự kiện** | **Mốc** | **Thời gian** | **Chi tiết** | | --- | --- | --- | | Bug introduced | 01/08/2010 | Commit `2032a93d66fa`, Linux 2.6.36 | | Kim submit kvmCTF | Trước 06/2026 | Dùng như 0-day, full escape | | Embargo bắt đầu | Trước 06/2026 | Report gửi [**linux-distros@vs.openwall.org**](mailto:linux-distros@vs.openwall.org) | | Patch merge mainline | 19/06/2026 | Commit `81ccda30b4e8` bởi Paolo Bonzini | | Embargo kết thúc | 06/07/2026 | Disclose lên oss-security | | Stable kernels patched | 04/07/2026 | 7 stable branches | | PoC public | 06/07/2026 | GitHub V4bel/Januscape | | Debian DSA-6381-1 | 05/07/2026 | testing/trixie và unstable/sid | ### **Distribution patch status (tại thời điểm xuất bản)** | **Branch** | **Phiên bản fixed** | | --- | --- | | v7.x | **7.1.3** | | v6.18.x | **6.18.38** | | v6.12.x | **6.12.95** | | v6.6.x | **6.6.144** | | v6.1.x | **6.1.177** | | v5.15.x | **5.15.211** | | v5.10.x | **5.10.260** | ## **MITRE ATT&CK Mapping** | **Tactic** | **Technique** | **Relevance** | | --- | --- | --- | | Privilege Escalation | **T1611** — Escape to Host | Core technique — thoát từ guest VM ra host | | Privilege Escalation | **T1068** — Exploitation for Privilege Escalation | Kernel UAF để leo quyền root | | Execution | **T1059.004** — Command and Scripting Interpreter: Unix Shell | Thực thi sau khi có shell trên host | | Impact | **T1499.004** — Endpoint Denial of Service: Application or System Exploitation | DoS path — crash host kernel | | Defense Evasion | **T1014** — Rootkit | Tiềm năng sau khi có host root, cài persistence | ## **Phát Hiện & Phản Ứng** ### **Detection — Phía Host** **Giám sát kernel panic signature:** * Nếu host bị tấn công qua DoS path, dmesg hoặc kernel log sẽ chứa: `kernel BUG at arch/x86/kvm/mmu/mmu.c:` `#Tìm cụ thể function pte_list_remove` `RIP: 0010:pte_list_remove+0x...` **Giám sát KVM module activity bất thường từ guest:** * Trong môi trường KVM có sử dụng nested virt, host có thể quan sát guest thao tác với VMX/SVM: `#Trên host, monitor kernel audit log cho kvm module events` `auditctl -w /dev/kvm -p rw -k kvm_access` **SIEM query pattern — phát hiện host panic liên quan KVM:** `# Elasticsearch / Kibana (syslog ingestion)` `event.dataset:syslog AND` `message:("kernel BUG" OR "BUG: unable to handle") AND` `message:"kvm"` ### **Detection — Phía Guest (Lateral Detection)** Nếu bạn vận hành từ phía guest và nghi ngờ có tenant khác đang tấn công host: `#Kiểm tra host đột ngột reboot / crash bất thường` `#So sánh uptime của tất cả VM cùng host` `who -b` `last reboot` ## **Nhận Định** CVSS 8.8 / 9.3 là con số phản ánh chính xác mức độ nghiêm trọng kỹ thuật — nhưng **rủi ro thực tế phụ thuộc vào một câu hỏi đơn giản:** host của bạn có chạy nested virtualization với tenant không tin tưởng không? Nếu không — ví dụ hạ tầng on-premise thuần túy, không có multi-tenant guest, hoặc tất cả guest VM đều do chính tổ chức kiểm soát — nguy cơ bị khai thác chủ động là thấp hơn đáng kể. Patch vẫn cần thực hiện, nhưng không ở mức độ khẩn cấp như với cloud provider. Ngược lại, nếu bạn vận hành **public cloud hoặc private cloud multi-tenant trên nền x86 KVM** — đây là vấn đề nghiêm trọng cần xử lý ngay. Một khách thuê bất kỳ, với không gì hơn quyền root trong VM của họ (điều kiện mặc định), có thể crash toàn bộ host và kéo theo mọi VM của các khách thuê khác. Đây là DoS hoàn toàn không yêu cầu kỹ năng cao — PoC đã public và hoạt động trong vài phút. **Về bối cảnh Việt Nam:** Hạ tầng cloud nội địa — từ các datacenter tier-3 cung cấp dịch vụ VPS cho đến private cloud enterprise — phần lớn chạy trên nền KVM/x86. Đáng lo ngại hơn là nested virtualization thường được bật mặc định hoặc theo yêu cầu khách hàng mà không có quy trình review security rõ ràng. Đây là thời điểm tốt để kiểm tra lại cấu hình và đưa "có bật nested virt không?" vào checklist onboarding tenant. **Pattern đáng chú ý từ Hyunwoo Kim:** Trong vòng chưa đầy 2 tháng, Kim đã công bố ba kernel exploit: DirtyFrag (CVE-2026-43284/CVE-2026-43500 — LPE qua page cache, tháng 5/2026), ITScape (CVE-2026-46316 — KVM escape đầu tiên trên ARM64, tháng 6/2026), và Januscape (CVE-2026-53359 — KVM escape trên x86, tháng 7/2026). Ba exploit này không chỉ là thành tích cá nhân — chúng nói lên rằng codebase KVM shadow paging, vốn là legacy code ít được review kỹ, đang có nhiều attack surface hơn cộng đồng nghĩ. Có thêm một chi tiết đáng chú ý: CVE-2026-46113 — một shadow MMU use-after-free khác liên quan đến rmap mismatch — đã được fix vào tháng 5/2026, chỉ một tháng trước Januscape. **Hai use-after-free trong cùng shadow paging code trong vòng hai tháng** là tín hiệu rõ ràng rằng đây là vùng code cần audit sâu hơn. ## **Khuyến Nghị Hành Động** ### **Immediate (0–24 giờ)** **Bước 1 — Kiểm tra phiên bản kernel hiện tại:** `uname -r` \=> Đối chiếu với bảng stable version ở trên **Bước 2 — Xác nhận nested virtualization có đang bật không:** `cat /sys/module/kvm_intel/parameters/nested` `cat /sys/module/kvm_amd/parameters/nested` \=> Output "Y" hoặc "1" = đang bật = có nguy cơ **Bước 3 — Nếu chưa thể patch ngay, tắt nested virt:** `echo "options kvm_intel nested=0" >> /etc/modprobe.d/kvm.conf` `echo "options kvm_amd nested=0" >> /etc/modprobe.d/kvm.conf` * Áp dụng ngay (nếu không có VM đang chạy cần nested virt) `modprobe -r kvm_intel && modprobe kvm_intel nested=0` `modprobe -r kvm_amd && modprobe kvm_amd nested=0` **Bước 4 — Kiểm tra permission /dev/kvm (nếu là host RHEL-based):** `ls -la /dev/kvm` \=> Nếu output là crw-rw-rw- (0666) → unprivileged user trong guest có thể LPE \=> Cân nhắc restrict về 0660 nếu không cần ### **Short-term (1–7 ngày)** * Patch kernel lên phiên bản stable đã fix theo bảng ở trên * Với distribution chưa có backport (Debian stable/bookworm, RHEL): theo dõi vendor tracker và áp dụng ngay khi có * Review toàn bộ host x86 KVM trong fleet — xây danh sách host nào có `nested=1` và có multi-tenant guest * Nếu dùng automation (Ansible, Puppet), thêm task kiểm tra `kvm_intel.nested` vào inventory scan ### **Long-term** * **Xem lại policy bật nested virtualization:** Nhiều tenant không thực sự cần nested virt. Mặc định tắt, bật theo yêu cầu có documented justification là cách tiếp cận an toàn hơn. * **Audit shadow paging code:** Với hai CVE trong hai tháng cùng khu vực code, đây là thời điểm để tổ chức xem xét đóng góp vào kernel review hoặc theo dõi closely các commit liên quan đến `arch/x86/kvm/mmu/`. * **Giám sát /dev/kvm permission trong tất cả guest template:** Đặc biệt với distro mặc định 0666 như RHEL — restrict về 0660 để loại bỏ LPE path không cần thiết. * **Cân nhắc triển khai QEMU / KVM trên host riêng biệt** cho multi-tenant workload có yêu cầu bảo mật cao, tách khỏi hạ tầng shared. ## **Bảng tra cứu & Link cập nhật bản vá theo từng Distribution** ### Upstream Linux Kernel * **Patch commit chính:** [81ccda30b4e8](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb) * **Companion fix:** `0cb2af2ea66a` | **Branch** | **Phiên bản fixed** | **Link tải nguồn** | | --- | --- | --- | | v7.x | ≥ **7.1.3** | [kernel.org/pub/linux/kernel/v7.x](https://www.kernel.org/pub/linux/kernel/v7.x/) | | v6.18.x | ≥ **6.18.38** | [kernel.org/pub/linux/kernel/v6.x](https://www.kernel.org/pub/linux/kernel/v6.x/) | | v6.12.x (LTS) | ≥ **6.12.95** | [kernel.org/pub/linux/kernel/v6.x](https://www.kernel.org/pub/linux/kernel/v6.x/) | | v6.6.x (LTS) | ≥ **6.6.144** | [kernel.org/pub/linux/kernel/v6.x](https://www.kernel.org/pub/linux/kernel/v6.x/) | | v6.1.x (LTS) | ≥ **6.1.177** | [kernel.org/pub/linux/kernel/v6.x](https://www.kernel.org/pub/linux/kernel/v6.x/) | | v5.15.x (LTS) | ≥ **5.15.211** | [kernel.org/pub/linux/kernel/v5.x](https://www.kernel.org/pub/linux/kernel/v5.x/) | | v5.10.x (LTS) | ≥ **5.10.260** | [kernel.org/pub/linux/kernel/v5.x](https://www.kernel.org/pub/linux/kernel/v5.x/) | ### Debian — Fixed * **Advisory:** [DSA-6381-1](https://www.debian.org/security/2026/dsa-6381) * **Tracker:** [security-tracker.debian.org](http://security-tracker.debian.org) * **Phiên bản fix:** `linux 7.1.3-1` (unstable/sid), `linux 6.12.95-1` (testing/trixie), `linux 5.10.223-1` (oldstable/bullseye). * **Lệnh cập nhật:** `sudo apt-get update && sudo apt-get upgrade linux-image-$(uname -r)` ### Red Hat / RHEL — Fixed * **Advisory:** [RHSA-2026:36957](https://access.redhat.com/errata/RHSA-2026:36957) (mức Important) * **Tracker:** [access.redhat.com/security/cve/cve-2026-53359](https://access.redhat.com/security/cve/cve-2026-53359) * **Phiên bản fix:** RHEL 9: `kernel-5.14.0-687.23.1.el9_8` hoặc cao hơn. * **Lệnh cập nhật:** `sudo dnf update kernel && sudo reboot` ### AlmaLinux — Fixed * **Advisory:** [ALSA-2026:36957](https://errata.almalinux.org/9/ALSA-2026-36957.html) (AlmaLinux 9), [ALSA-2026:36956](https://errata.almalinux.org/10/ALSA-2026-36956.html) (AlmaLinux 10) * **Phiên bản fix:** AL9: `kernel-5.14.0-687.23.1.el9_8`; AL10: `kernel-6.12.0-211.32.1.el10_2`. * **Lệnh cập nhật:** `sudo dnf update kernel && sudo reboot` ### Rocky Linux — Fixed * **Advisory:** [RLSA-2026:36957](https://errata.rockylinux.org/RLSA-2026:36957) (Rocky Linux 9), [RLSA-2026:36956](https://errata.rockylinux.org/) (Rocky Linux 10) * **Phiên bản fix:** RL9: `kernel-5.14.0-687.24.1.el9_8`; RL10: `kernel-6.12.0-211.32.1.el10_2`. * **Lệnh cập nhật:** `sudo dnf update kernel && sudo reboot` ### Oracle Linux — Fixed * **Advisory:** [ELSA-2026-36957](https://linux.oracle.com/errata/ELSA-2026-36957.html) (Oracle Linux 9), [ELSA-2026-39083](https://linux.oracle.com/errata/ELSA-2026-39083.html) (Oracle Linux 8) ### Fedora — Fixed * **Advisory:** [FEDORA-2026-c3e2e91b4d](https://bodhi.fedoraproject.org/updates/FEDORA-2026-c3e2e91b4d) (Fedora 43) * **Tracker:** [bodhi.fedoraproject.org](http://bodhi.fedoraproject.org) * **Lệnh cập nhật:** `sudo dnf update kernel && sudo reboot` ### Arch Linux — Fixed * **Tracker:** [security.archlinux.org](http://security.archlinux.org) * **Lệnh cập nhật:** `sudo pacman -Syu` ### Ubuntu — Pending (Chưa phát hành bản vá chính thức) * **Tracker:** [ubuntu.com/security/CVE-2026-53359](https://ubuntu.com/security/CVE-2026-53359) * **Lưu ý:** Canonical đang chuẩn bị bản vá. Hãy theo dõi link trên để cập nhật ngay khi USN được phát hành. ### SUSE / openSUSE — Pending (Chưa phát hành bản vá chính thức) * **Bug tracker:** bsc#1270059 * **Tracker:** [suse.com/security/cve/CVE-2026-53359](https://www.suse.com/security/cve/CVE-2026-53359.html) (SLE 15 SP7, openSUSE Leap) * **Lệnh cập nhật (sau khi phát hành:** `sudo zypper refresh && sudo zypper patch` ### Các Distribution khác * **Amazon Linux:** Xem tại [alas.aws.amazon.com](http://alas.aws.amazon.com) (tìm kiếm CVE-2026-53359) * **Gentoo:** Xem tại [security.gentoo.org/glsa](https://security.gentoo.org/glsa/) (tìm kiếm CVE-2026-53359) ## Tham Khảo [16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host on Intel and AMD x86 Systems](https://thehackernews.com/2026/07/16-year-old-linux-kvm-flaw-lets-guest.html) [V4bel (@v4bel) / X](https://x.com/v4bel) [security-research/pocs/linux/kernelctf/CVE-2024-50264\_lts\_cos/docs/](https://github.com/google/security-research/blob/09335abb6b01ee706a5a5584278ef4c4c1d50bda/pocs/linux/kernelctf/CVE-2024-50264_lts_cos/docs/exploit.md)[exploit.md](http://exploit.md) [at 09335abb6b01ee706a5a5584278ef4c4c1d50bda · google/security-research · GitHub](https://github.com/google/security-research/blob/09335abb6b01ee706a5a5584278ef4c4c1d50bda/pocs/linux/kernelctf/CVE-2024-50264_lts_cos/docs/exploit.md) [New Januscape Linux flaw allows VM escape on Intel, AMD devices](https://www.bleepingcomputer.com/news/linux/new-januscape-linux-kernel-flaw-allows-vm-escape-on-intel-amd-devices/)