Chỉ trong vòng hai tuần, cộng đồng Linux phải đối mặt với lỗ hổng leo thang đặc quyền nghiêm trọng thứ hai: "Dirty Frag" — kết hợp hai lỗ hổng kernel để cho phép người dùng thấp quyền chiếm quyền root. Mã khai thác PoC đã lưu hành công khai, và Microsoft xác nhận đã quan sát thấy dấu hiệu khai thác trong môi trường thực tế.
Dirty Frag là gì và tại sao nó nguy hiểm hơn các lỗ hổng thông thường?
Dirty Frag được nhà nghiên cứu Hyunwoo Kim công bố cuối tuần trước. Ngay sau khi công bố, một bên thứ ba đã rò rỉ chi tiết kỹ thuật, buộc chính Kim phải phát hành mã nguồn PoC. Theo Ars Technica, mã khai thác đã xuất hiện trực tuyến từ ba ngày trước và được xác nhận hoạt động ổn định trên hầu hết các distro Linux phổ biến.
Điểm khiến Dirty Frag đặc biệt đáng lo ngại là tính quyết định luận (deterministic): mỗi lần chạy đều cho kết quả giống nhau, không gây crash hệ thống, và hoạt động nhất quán bất kể distro. Điều này khiến việc phát hiện tấn công trở nên cực kỳ khó khăn.
Cuộc tấn công khai thác hai lỗ hổng kernel:
- CVE-2026-43284 (CVSS 8.8 — HIGH): Tồn tại trong hàm
esp_input()của đường xử lý nhận IPsec ESP, nhắm vào tiến trình esp4 và esp6. - CVE-2026-43500 (CVSS 7.8 — HIGH): Tồn tại trong
rxkad_verify_packet_1(), nhắm vào thành phần RxRPC.
Cả hai lỗ hổng đều liên quan đến cách kernel xử lý page cache trong bộ nhớ. Kẻ tấn công dùng lệnh splice() để nhúng tham chiếu đến page cache chỉ-đọc (ví dụ /etc/passwd hoặc /usr/bin/su) vào frag slot của socket buffer (sk_buff). Khi kernel thực hiện xử lý mã hóa trên frag đó, nội dung page cache trong RAM bị ghi đè — cho phép kẻ tấn công chỉ có quyền đọc vẫn thấy phiên bản đã bị sửa đổi trong các lần đọc file tiếp theo.
Automox xếp Dirty Frag vào cùng họ lỗ hổng với Dirty Pipe (2022) và Copy Fail (tuần trước), nhưng điểm mới là mục tiêu tấn công: thay vì pipe_buffer, Dirty Frag nhắm vào thành phần frag của cấu trúc sk_buff.
Hai CVE đơn lẻ không đủ — nhưng kết hợp lại thì phá vỡ mọi distro chính
Khi sử dụng riêng lẻ, mỗi lỗ hổng đều có điểm yếu:
- Trên một số cấu hình Ubuntu, AppArmor ngăn người dùng không tin cậy tạo namespace, vô hiệu hóa hướng tấn công qua ESP.
- Nhiều distro mặc định không tải
rxrpc.ko, vô hiệu hóa hướng tấn công qua RxRPC.
Tuy nhiên, khi kết hợp cả hai CVE, Hyunwoo Kim xác nhận đã chiếm được quyền root thành công trên tất cả các distro chính mà ông kiểm tra. Đáng chú ý, lỗ hổng xfrm-ESP đã tồn tại từ năm 2017 và RxRPC từ năm 2023 — nghĩa là các kernel được phát hành trong 9 năm qua đều có thể bị ảnh hưởng.
Một điểm quan trọng: Dirty Frag không bị chặn bởi biện pháp giảm thiểu của Copy Fail. Việc blacklist module algif_aead — giải pháp được áp dụng cho lỗ hổng tuần trước — hoàn toàn không có tác dụng với Dirty Frag.
Môi trường nào có nguy cơ cao nhất?
Microsoft đã công bố chuỗi tấn công thực tế được quan sát: SSH từ bên ngoài → tạo interactive shell → triển khai ELF binary (./update) → leo thang đặc quyền qua su. Đây là quy trình tấn công hoàn chỉnh, không chỉ là thử nghiệm lý thuyết.
Các môi trường có nguy cơ cao nhất bao gồm:
- VPS và máy chủ dùng chung: Nhiều người dùng cùng SSH vào một máy chủ là điều kiện lý tưởng để khai thác.
- Máy ảo (VM): Rủi ro cao hơn so với container được tăng cường bảo mật.
- OpenShift Container Platform 4: Red Hat xác nhận bị ảnh hưởng, phát hành thông báo RHSB-2026-003.
Ngược lại, theo Wiz (thuộc Google), các môi trường container được tăng cường với cấu hình bảo mật mặc định như Kubernetes — có seccomp profile và yêu cầu CAP_NET_ADMIN — có khả năng thấp bị khai thác thoát container. Tuy nhiên, đây không phải lý do để trì hoãn vá lỗi.
Ubuntu lưu ý rõ: trên máy chủ không chạy container, người dùng local có thể leo thang lên root; trên môi trường container chạy workload bên thứ ba, thoát container vẫn là khả năng thực tế.
Trạng thái vá lỗi và hành động cần thực hiện ngay
Cả hai CVE đã được vá trong Linux kernel mainline:
- CVE-2026-43284: commit
f4c50a4034e6 - CVE-2026-43500: commit
aa54b1d27fe0
Lỗ hổng được báo cáo cho maintainer kernel ngày 30/4/2026.
| Distro | Trạng thái |
|---|---|
| Debian | ✅ Đã có patch bản production |
| AlmaLinux | ✅ Đã có patch bản production |
| Fedora | ✅ Đã có patch bản production |
| Red Hat / OpenShift | ⚠️ Có biện pháp giảm thiểu (blacklist module, không cần reboot) |
| Các distro khác | 🔍 Kiểm tra kênh chính thức của nhà cung cấp |
Hành động ưu tiên:
- Cập nhật kernel ngay lập tức nếu đang dùng Debian, AlmaLinux hoặc Fedora — có thể cần reboot.
- Với Red Hat/OpenShift: Áp dụng blacklist kernel module theo hướng dẫn RHSB-2026-003 (không cần reboot node).
- Với các distro chưa có patch: Theo dõi kênh bảo mật chính thức và áp dụng biện pháp giảm thiểu tạm thời từ nhà cung cấp.
- Ưu tiên cao nhất cho máy chủ có SSH mở ra ngoài, VPS dùng chung, và môi trường multi-tenant.
Đối với quản trị viên hệ thống tại Việt Nam — đặc biệt những người vận hành VPS, hosting chia sẻ, hoặc hạ tầng cloud nội địa — đây là bản cập nhật cần xử lý trong vòng 24 giờ, không phải lịch bảo trì định kỳ. Với PoC đã công khai và dấu hiệu khai thác thực tế được Microsoft xác nhận, thời gian phản ứng trực tiếp quyết định mức độ rủi ro.
