Đã đăng vào Thứ Bảy, 3:48 SA 23 phút đọc

ITScape: từ một race condition gây ra ngắt trở thành một lỗ hổng khổng lồ

Bạn đang chạy web, app của mình trên một con VM của cloud provider (từ shared host, VPS, đến các Firecracker như EC2 của AWS, hay kể cả VM trên homelab trong nhà bạn). Bạn nghĩ rằng máy ảo của mình được cách ly với các máy ảo khác trên cùng một host. Nhưng vào tháng 6/2026, một lỗ hổng tên ITScape cho thấy sự cách ly đó có thể bị phá vỡ từ bên trong một máy ảo khác.

Không cần quyền truy cập data center. Không cần hack vào mạng của provider. Chỉ cần kẻ tấn công thuê được một máy ảo trên cùng host vật lý, và host đó chạy kernel Linux chưa được vá.

1. Ngắt (interrupt) là gì? Và tại sao nó liên quan đến cloud?

Trong điện tử và lập trình nhúng, interrupt là tín hiệu bắt CPU phải tạm dừng việc đang làm để xử lý một sự kiện khẩn cấp. Sau khi xử lý xong trong ISR (Interrupt Service Routine), CPU quay lại tiếp tục công việc cũ. Ngắt giúp hệ thống phản ứng nhanh mà không cần lãng phí CPU vào việc kiểm tra liên tục (polling).

Để hiểu rõ hơn, hãy nhìn vào một nhân logic. Mỗi nhân logic chỉ có thể làm một việc tại một thời điểm. Nó làm việc theo thứ tự, giống như một nhân viên đang xử lý từng tờ hóa đơn trên bàn. Công việc đang làm nằm ở trên cùng, còn các công việc chờ xử lý nằm trong hàng chờ.

Khi có interrupt, giống như một cuộc điện thoại khẩn cấp reo lên. CPU không thể nói "Để tôi xong việc này đã" nếu sự kiện đó đòi hỏi phản ứng ngay lập tức. Thay vào đó, CPU:

Dừng việc hiện tại và lưu lại trạng thái đang làm dở.
Chen cuộc điện thoại ngắt vào hàng chờ với mức ưu tiên cao hơn công việc thường.
Chạy ISR để xử lý sự kiện.
Sau khi xong, quay lại công việc bị gián đoạn.

Điểm quan trọng là interrupt được ưu tiên thực hiện trước so với các tác vụ thông thường. Đây là lý do ngắt giúp hệ thống phản ứng kịp thời: nó chen ngang vào đầu hàng chờ, không xếp hàng sau các công việc khác.

Khi bạn lên cloud, máy ảo của bạn cũng cần xử lý ngắt. Card mạng ảo nhận được request? Ngắt. Ổ đĩa ảo hoàn thành I/O? Ngắt. Trên kiến trúc ARM64, phần cứng quản lý ngắt gọi là GIC (Generic Interrupt Controller), và thành phần dịch ngắt từ các thiết bị PCIe gọi là ITS (Interrupt Translation Service).

Và trong máy ảo, Linux kernel trên host phải giả lập ITS bằng phần mềm, gọi là vGIC-ITS. Mọi thao tác ngắt của máy ảo đều đi qua code này trong host kernel.

Và chính trong code giả lập đó, một lỗi nhỏ đã mở ra lối thoát cho mã độc từ máy ảo nhảy ra ngoài máy chủ vật lý, có thể thực thi và gây ảnh hưởng lên toàn bộ các máy ảo khác.

2. Máy ảo là gì? Và tại sao cloud cần nó?

Trước khi đi sâu vào lỗ hổng, hãy ôn lại khái niệm máy ảo (virtual machine, hay VM).

Một máy chủ vật lý có thể rất mạnh: nhiều CPU core, hàng trăm GB RAM, nhiều ổ đĩa. Nhưng nếu một công ty thuê nguyên một máy chủ vật lý như vậy chỉ để chạy một app nhỏ, phần lớn tài nguyên sẽ bị lãng phí. Và thường các cá nhân, công ty nhỏ không có khả năng làm điều này vì chi phí quá đắt đỏ. Hoạ chăng enterprises lớn mới có thể chi trả hoá đơn này. Máy ảo giải quyết vấn đề này bằng cách chia một máy chủ vật lý thành nhiều máy ảo nhỏ hơn, mỗi cái chạy hệ điều hành và ứng dụng riêng. Từ đó, bạn có thể thuê lại 1 máy ảo để chạy app với giá cả phải chăng hơn.

Ví dụ, hình dung một tòa nhà chung cư là máy chủ vật lý, các căn hộ là máy ảo. Mỗi căn hộ có không gian riêng, công tơ điện nước riêng, và ngưởi ở riêng. Họ chia sẻ móng, tường chịu lực, và hệ thống đường ống điện nước chung, nhưng tường ngăn, cửa khoá khiến họ không thể tự ý bước sang nhà nhau.

Trên cloud, điều tương tự xảy ra. Cloud provider có một máy chủ vật lý, dùng phần mềm gọi là hypervisor (ví dụ KVM) để tạo ra nhiều máy ảo. Mỗi khách hàng thuê một hoặc vài máy ảo. Mô hình này gọi là multi-tenant, tức nhiều ngưởi thuê chung một tài sản vật lý. Mô hình này rất phổ biến.

Lợi ích của máy ảo:

Tiết kiệm chi phí: bạn chỉ trả tiền cho tài nguyên bạn dùng.
Linh hoạt: tạo, xóa, thay đổi kích thước VM trong vài phút.
Cách ly: lỗi trong máy ảo này lý thuyết không ảnh hưởng máy ảo khác.

Điểm then chốt là cách ly. Nếu một căn hộ có thể đột nhập sang căn hộ khác, hoặc vào phòng điều khiển của tòa nhà, thì toàn bộ mô hình chung cư sẽ sụp đổ. ITScape và Januscape chính là những lỗ hổng tường ngăn đó.

3. ITScape (CVE-2026-46316): vấn đề không nằm ở ứng dụng của bạn

ITScape là lỗ hổng trong nhân Linux, cụ thể là trong hàm vgic_its_invalidate_cache() của KVM ARM64. (Hiểu đơn giản: nhân Linux và kernel là lớp phần mềm nối giữa phần cứng và các ứng dụng của bạn. Nó quản lý bộ nhớ, thiết bị, và quyền truy cập. Nó như ban quản lý toà nhà, còn phần cứng là toà nhà.) Bạn không cần nhớ tên hàm. Chỉ cần hiểu: đây là hàm xóa bộ nhớ đệm của bộ dịch ngắt ảo.

Khi nhiều luồng xử lý cùng gọi hàm này, chúng có thể cùng xóa và giải phóng một vùng nhớ. Kết quả là vùng nhớ bị giải phóng hai lần, gọi là double-put, dẫn đến use-after-free. Kẻ tấn công từ máy ảo có thể chiếm lại vùng nhớ đó, giả mạo cấu trúc dữ liệu của kernel, và chạy code với quyền cao nhất trên host.

Điểm đáng sợ: lỗi nằm trong in-kernel KVM, tầng rất sâu trong máy chủ vật lý, không phải trong QEMU hay userspace VMM. Nghĩa là dù provider dùng công nghệ gì, QEMU, Cloud Hypervisor, Firecracker hay Kata Containers. Chỉ cần họ expose GIC ITS cho máy ảo ARM64 là có thể bị ảnh hưởng.

Bạn có bị ảnh hưởng không?

Bạn bị ảnh hưởng nếu đồng thời thỏa mãn:

Bạn đang dùng máy ảo ARM64 trên cloud (hoặc on-prem KVM).
Host kernel chưa được vá patch 13031fb6b835 (hoặc các backport tương ứng).
Kẻ tấn công có thể thuê/chiếm một máy ảo khác trên cùng host vật lý.

Về số phiên bản kernel, ITScape bị ảnh hưởng từ Linux 6.10 trở lên cho đến trước các bản vá stable. Cụ thể:

Bị ảnh hưởng: kernel từ 6.10 trở lên, chưa có patch.
Đã được sửa trong: 6.12.93, 6.18.35, 7.0.12, và 7.1-rc7 (commit 13031fb6b835).

Nếu provider của bạn chạy kernel trong khoảng các version bị ảnh hưởng và chưa cập nhật, máy ảo ARM64 của bạn có rủi ro.

Nếu bạn chỉ dùng máy ảo x86_64 (Intel/AMD), ITScape không ảnh hưởng đến bạn. Lý do đơn giản: lỗi nằm trong code ARM64-specific (nhưng sẽ có thứ khác tương tự, sẽ nói sau).

Các instance ARM64 phổ biến: AWS Graviton (t families), Azure Cobalt, Google Cloud Axion, Ampere Altra trên nhiều provider nhỏ.

4. Januscape (CVE-2026-53359): phiên bản x86_64, nhưng khó kích hoạt hơn

Ngay sau ITScape, giới bảo mật phát hiện Januscape, lỗ hổng tương tự trên x86_64, ảnh hưởng cả Intel và AMD. Lỗi này tồn tại trong mã nguồn Linux từ năm 2010 (commit 2032a93d66fa) cho đến khi được sửa với commit 81ccda30b4e8 (16/06/2026).

Tuy nhiên, Januscape cần nested virtualization mới kích hoạt được. Nghĩa là máy ảo của bạn phải được phép chạy hypervisor bên trong nó (L1 chạy L2). Hầu hết các cloud provider lớn không bật nested virtualization cho instance thuê thông thường. Nếu bạn không cố ý bật nested virtual trên VM của mình, bạn không cần lo lắng nhiều về Januscape.

Về số phiên bản, Januscape bị ảnh hưởng trên các kernel x86_64 cũ hơn và được sửa với commit 81ccda30b4e8 vào giữa tháng 6/2026. Do điều kiện kích hoạt khó hơn, rủi ro đối với người dùng cloud thường thấp hơn nhiều so với ITScape.

Vậy nên trong thực tế:

ITScape đáng lo hơn vì nó kích hoạt trên ARM64 VM bình thường. Chip ARM là chip rất tiết kiệm điện, giá thành rẻ nên thường được sử dụng phổ biến.
Januscape chủ yếu là rủi ro với các môi trường dev/test cho phép nested virtualization, hoặc các private cloud tự quản lý.

5. Hậu quả thực tế với bạn là gì?

Nếu một kẻ tấn công khai thác thành công trên host đang chạy VM của bạn, họ có thể:

Đọc dữ liệu của bạn từ bộ nhớ vật lý, bao gồm RAM của máy ảo bạn cùng toàn bộ các khách thuê cùng máy chủ vật lý.
Can thiệp vào network hoặc disk I/O của bạn.
Làm sập toàn bộ host, khiến VM của bạn bị downtime.

Điều quan trọng: bạn không thể tự vá lỗi này. Kernel host do cloud provider quản lý. Bạn không có quyền can thiệp vào hypervisor.

Vậy nâng kernel trên VPS của bạn có giúp được không?

Không. Khi bạn chạy lệnh uname -r trên VPS, bạn đang nhìn thấy kernel của máy ảo guest, tức là hệ điều hành mà bạn tự cài bên trong VM. Lỗi ITScape không nằm ở đây. Nó nằm ở kernel của máy chủ vật lý (host kernel), nơi hypervisor chạy.

Bạn có thể tự cập nhật kernel bên trong VPS lên 6.12.93 hay 7.1-rc7, nhưng điều đó không bảo vệ bạn khỏi ITScape. Vì kernel host bên ngoài máy ảo vẫn có thể là 6.10, chưa được vá. Hãy tưởng tượng bạn thay khóa cửa căn hộ của mình, nhưng tường chung cư vẫn có lỗ hổng. Bạn không thể tự sửa tường, giầm chung cư.

Vậy cần làm gì? Cầu nguyện... à thực ra thì các provider lớn thường sẽ có đội red team và quản trị data center khắt khe, nên hầu hết những lỗ hổng đã được khám phá sẽ được vá ngay. Đó là vì sao mà giá đi kèm với chất lượng. (zero day thì chịu)

6. AI agent làm rủi ro này thay đổi như thế nào?

Năm 2026 là thời kỳ mà các tác nhân tự hành (AI agent) chạy tự động trên cloud. Khi kết hợp hai xu hướng này, một số tình huống mới xuất hiện.

Tình huống 1: Attacker dùng AI agent để tấn công hàng loạt

Khai thác ITScape không phải chuyện một phát ăn ngay. Cần thuê VM, chạy PoC, điều chỉnh tham số, theo dõi kết quả, và lặp lại khi cross-cache miss hoặc KASLR leak chưa thành công. Trước đây, một kẻ tấn công có thể mất hàng vài ngày để làm thủ công.

Với AI agent, họ có thể:

Tự động thuê hàng trăm VM giá rẻ trên nhiều provider khác nhau.
Chạy exploit với các tham số khác nhau trên từng instance.
Thu thập kết quả, phân loại instance nào dễ bị, instance nào không.
Tự động chuyển sang region/provider mới khi bị phát hiện hoặc hết quota.

AI không "tự nghĩ ra" lỗ hổng. Nó chỉ là công cụ scale, giống như robot thử hàng triệu chìa khóa thay vì một tên trộm ngồi thủ công. Chi phí tấn công giảm, tốc độ tăng, và số lượng mục tiêu có thể đuổi theo tăng theo cấp số nhân.

Tình huống 2: Agent chạy trong sandbox vô tình kích hoạt lỗi

Nhiều developer đang chạy AI agent trong container hoặc VM để thử nghiệm. Họ nghĩ: "Agent chỉ chạy bên trong sandbox, dù nó có làm gì đi nữa cũng không ảnh hưởng ra ngoài."

Nhưng nếu sandbox đó là một VM trên host chưa vá ITScape hoặc Januscape, agent có thể vô tình kích hoạt race condition bằng các hành động hoàn toàn bình thường:

Tạo và xóa nhiều nested VM hoặc virtual device.
Chạy stress test hoặc benchmark trên nhiều vCPU.
Thực hiện các thao tác mà nó được phép làm, nhưng với tần suất và thời điểm vừa trùng khớp để trigger race.

Agent không cần biết về CVE-2026-46316. Nó chỉ cần thực hiện đúng chuỗi hành động được phép trên một hệ thống chưa được vá. Bùm, sập cả toà nhà.

Tình huống 3: Agent tự hành, tự quản lý máy chủ

Đây là tình huống xa hơn một chút nhưng đáng để nghĩ đến. Agent đã có thể được giao quyền:

Tự động thuê VM trên cloud.
Cấu hình firewall, deploy app, scale cluster.
Tự quyết định nên chạy workload nào ở đâu.
Quản lý incidents.

Nếu một agent như vậy bị tấn công từ trong 1 VM, hoặc có bug dẫn đến hành vi không mong muốn, nó có thể:

Tự động thuê VM trên các host chưa patch.
Vô tình chạy các workload kích hoạt race condition.
Hoặc bị kẻ xấu điều khiển để mở rộng tấn công trên quy mô lớn.

Điểm chung của cả ba tình huống: lỗ hổng hypervisor càng nguy hiểm hơn khi có tự động hóa. Con người có thể mệt và chán. Agent thì không.

7. Những gì bạn có thể làm

7.1. Kiểm tra xem bạn có đang dùng ARM64 không

Trên Linux VM:

uname -m

Nếu kết quả là aarch64, bạn đang trên ARM64. Nếu là x86_64, ITScape không áp dụng.

Trên AWS, bạn cũng có thể kiểm tra instance type:

curl -s http://169.254.169.254/latest/meta-data/instance-type

Các family kết thúc bằng g (Graviton) thường là ARM64, ví dụ t4g, m7g, r8g, c8g.

7.2. Hỏi provider về trạng thái patch

Nếu bạn dùng ARM64 VM, hãy kiểm tra:

Kernel version trên host mà provider công bố (nếu có). Bạn muốn thấy ít nhất 6.12.93, 6.18.35, 7.0.12, hoặc 7.1-rc7 trở lên.
Security advisory của provider về CVE-2026-46316.
Nếu provider không công khai, mở ticket hỏi: "Has the host kernel been patched against CVE-2026-46316 (ITScape) for ARM64 instances?"

Đừng ngại hỏi. Đây là câu hỏi hợp lệ từ một khách hàng trả tiền.

7.3. Kiểm tra phiên bản kernel nếu bạn là quản trị host (không phải tenant thuê VPS)

Chỉ khi nào bạn tự quản lý máy chủ vật lý ARM64 chạy KVM, ví dụ homelab, on-prem server, hoặc bạn chính là provider - bạn mới có thể vá kernel host. Trong trường hợp đó, hãy đảm bảo kernel có patch:

# Kiểm tra xem patch đã được backport chưa trên kernel host
uname -r

Và cập nhật kernel lên bản stable mới nhất.

7.4. Giảm thiểu rủi ro ở tầng ứng dụng - việc duy nhất tenant VPS có thể chủ động

Với người thuê VPS thông thường, bạn không vá được kernel host. Nhưng bạn có thể làm vài việc để giảm thiệt hại nếu rủi ro xảy ra:

Mã hóa dữ liệu nhạy cảm ở rest và in transit: Nếu attacker đọc được RAM, dữ liệu đã mã hóa sẽ khó khai thác hơn. Lưu ý: RAM của VM vẫn chứa plaintext khi đang chạy, nên đây chỉ là lớp giảm thiệt hại, không phải giải pháp hoàn hảo.
Không lưu secret thô trong RAM không cần thiết: đọc credential từ vault khi cần, xóa khỏi bộ nhớ sau dùng.
Tách biệt workload: đừng để tất cả dữ liệu nhạy cảm trên một VM duy nhất.
Backup và disaster recovery: nếu host bị sập, bạn cần khôi phục nhanh.
Theo dõi advisory: đăng ký nhận thông báo bảo mật từ provider và Linux kernel.

7.5. Với Januscape trên x86_64

Nếu bạn quản lý host x86_64 có bật nested virtualization cho khách hàng, hãy cập nhật kernel hoặc tắt nested virtual tạm thời cho đến khi patch xong.

Nếu bạn chỉ là tenant thuê VM x86_64 thông thường, rủi ro Januscape rất thấp.

8. Tại sao một lỗi nhỏ lại gây tác động lớn đến vậy?

Hồi xưa học điện tử, mình từng lập trình ngắt trên vi điều khiển. Ngắt là một trong những cơ chế cốt lõi của hệ thống máy tính. Nếu code quản lý ngắt sai, CPU có thể chạy sai hàm, mất dữ liệu, hoặc crash.

ITScape là minh chứng ở quy mô lớn hơn nhiều. Một hàm xóa cache trong bộ giả lập ngắt của ARM64 bị race condition. Không cần phải lỗi mã hóa, không phải lỗi network protocol. Hậu quả là toàn bộ ranh giới giữa máy ảo và máy chủ vật lý bị phá vỡ. Giống như bạn đang mua một căn chung cư mà người hàng xóm có chìa khoá vạn năng có thể vào phòng bạn bất cứ lúc nào.

Điều này cũng nhắc nhở chúng ta về shared tenancy. Cloud rẻ và tiện, nhưng bạn đang chia sẻ phần cứng với người khác. Khi lớp cách ly hypervisor có lỗ hổng, sự cách ly đó không còn ý nghĩa.

Tạm kết

ITScape là một lỗ hổng nghiêm trọng, nhưng đối với hầu hết người dùng cloud:

Xác định bạn có đang dùng ARM64 VM không.
Hỏi provider host kernel đã được vá chưa.
Giảm thiểu rủi ro ở tầng ứng dụng bằng mã hóa, tách workload, và backup.

Bạn không cần hiểu sâu từng dòng code vgic_its_invalidate_cache(). Bạn chỉ cần biết rằng sự cách ly máy ảo không phải là tuyệt đối, và đôi khi một lỗi nhỏ trong phần mềm giả lập phần cứng có thể ảnh hưởng đến cả data center.

Nếu bạn đang chạy workload trên ARM64 cloud, hãy dành 10 phút kiểm tra instance type và security advisory của provider. Đó là 10 phút có thể giúp bạn ngủ ngon hơn 2 ngày cuối tuần này.

Bạn có đang chạy AI agent hoặc sandbox nào trên cloud ARM64 không? Bạn đã từng kiểm tra xem provider của mình đã vá các lỗ hổng như ITScape chưa? Hãy chia sẻ ở dưới để cùng thảo luận.

References

ITScape PoC và write-up: https://github.com/V4bel/ITScape
Januscape PoC và write-up: https://github.com/V4bel/Januscape
Patch ITScape (13031fb6b835): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13031fb6b8357fbbcded2a7f4cba73e4781ee594
Linux CVE announce ITScape (các bản stable bị ảnh hưởng và đã fix): https://lists.openwall.net/linux-cve-announce/2026/06/09/3
Patch Januscape (81ccda30b4e8): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81ccda30b4e8
Thông báo oss-security ITScape: https://www.openwall.com/lists/oss-security/2026/06/10/16
Thông báo oss-security Januscape: https://www.openwall.com/lists/oss-security/2026/07/06/7