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) |
Đ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). |
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=1hoặckvm_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.
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.
Đị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ể
Guest tạo một PDE (Page Directory Entry) trỏ tới large 2MB page → KVM cấp shadow page với
direct=1Guest thay đổi PDE đó để trỏ sang non-leaf page (4KB) → KVM cần shadow page với
direct=0kvm_mmu_get_child_sp()tìm thấy shadow page cũ có GFN khớp, reuse nó mà không kiểm tra roleKVM cài đặt leaf SPTE (4KB) trên shadow page có
direct=1— record rmap entry theo GFN tính từsp->gfn + indexthay vìsp->shadowed_translation[]Khi shadow page bị xóa,
rmap_remove()tính GFN sai → không xóa được rmap entry → dangling pointerKhi memslot bị drop, shadow page được giải phóng nhưng rmap entry vẫn tồn tại
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
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ả |
|
|
| Định tuyến kiến trúc ảo hóa: |
|
|
| Số lượng thread vCPU tham gia vào quá trình tạo race condition. |
|
|
| Thời gian nghỉ (tính bằng microgiây - µs) của thread WRITER trong mỗi vòng lặp. |
|
|
| Thời gian sống tối đa (timeout) của toàn bộ PoC (600.000 ms = 10 phút). |
|
|
| Cờ (flag) cho phép in log chẩn đoán lỗi ra màn hình (1 = Bật). |
|
|
| 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:
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 đó.
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:
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 |
|---|---|---|---|
| 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=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):
WRITER thread chạy vòng lặp tight:
FAULT thread trigger page fault tại GVA_PRIME trong L2:
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:
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:
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:
Đ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):
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 |
| 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:<line_number>
#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=1và có multi-tenant guestNếu dùng automation (Ansible, Puppet), thêm task kiểm tra
kvm_intel.nestedvà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
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 |
| v6.18.x | ≥ 6.18.38 | kernel.org/pub/linux/kernel/v6.x |
| v6.12.x (LTS) | ≥ 6.12.95 | kernel.org/pub/linux/kernel/v6.x |
| v6.6.x (LTS) | ≥ 6.6.144 | kernel.org/pub/linux/kernel/v6.x |
| v6.1.x (LTS) | ≥ 6.1.177 | kernel.org/pub/linux/kernel/v6.x |
| v5.15.x (LTS) | ≥ 5.15.211 | kernel.org/pub/linux/kernel/v5.x |
| v5.10.x (LTS) | ≥ 5.10.260 | kernel.org/pub/linux/kernel/v5.x |
Debian — Fixed
Advisory: DSA-6381-1
Tracker: 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 (mức Important)
Phiên bản fix: RHEL 9:
kernel-5.14.0-687.23.1.el9_8hoặc cao hơn.Lệnh cập nhật:
sudo dnf update kernel && sudo reboot
AlmaLinux — Fixed
Advisory: ALSA-2026:36957 (AlmaLinux 9), ALSA-2026:36956 (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 (Rocky Linux 9), RLSA-2026:36956 (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 (Oracle Linux 9), ELSA-2026-39083 (Oracle Linux 8)
Fedora — Fixed
Advisory: FEDORA-2026-c3e2e91b4d (Fedora 43)
Tracker: bodhi.fedoraproject.org
Lệnh cập nhật:
sudo dnf update kernel && sudo reboot
Arch Linux — Fixed
Tracker: 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
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 (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 (tìm kiếm CVE-2026-53359)
Gentoo: Xem tại 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
security-research/pocs/linux/kernelctf/CVE-2024-50264_lts_cos/docs/exploit.md at 09335abb6b01ee706a5a5584278ef4c4c1d50bda · google/security-research · GitHub
New Januscape Linux flaw allows VM escape on Intel, AMD devices
