Tenbyte Cloud phản hồi lỗ hổng khai thác "Copy Fail" Local Root

TL;DR: Một lỗ hổng LPE nghiêm trọng trong kernel Linux đã được công bố vào ngày 29/4/2026. Nó ảnh hưởng tới mọi bản phân phối Linux chính kể từ 2017 và đã có mã khai thác công khai hoạt động. Nền tảng Tenbyte Cloud không bị ảnh hưởng — cách ly VM ngăn chặn việc khai thác chéo khách hàng. Các máy chủ Linux cá nhân của bạn vẫn cần được vá. Cập nhật kernel và khởi động lại.

Vào ngày 29/4/2026, các nhà nghiên cứu bảo mật tại Theori đã công bố một lỗ hổng nâng quyền cục bộ (LPE) trong kernel Linux. Nó được gọi là "Copy Fail" — và là một trong những LPE nguy hiểm nhất.

Lỗi nằm trong giao diệnalgif_aead của kernel. Bằng cách lợi dụng lệnh hệ thốngsplice() qua AF_ALG, một tiến trình không có quyền có thể ghi dữ liệu tùy ý trực tiếp vào cache trang của host. Từ đó, việc ghi đè/etc/passwd hoặc chèn khóa SSH vào/root/.ssh/authorized_keys trở nên đơn giản. Shell root đầy đủ, không cần thời gian tranh chấp, không cần tính toán offset kernel.

Mã khai thác công khai có dung lượng732 byte Python. Nó hoạt động ổn định trên Ubuntu, Amazon Linux, RHEL và SUSE — mọi bản phân phối kể từ kernel 4.14 (2017).

Điều đáng chú ý hơn cả lỗi là cách nó được phát hiện: hệ thống AI Xint Code của Theori đã phát hiện trong vòng khoảng một giờ chỉ với một lời nhắc. Không cần harness, không cần triage thủ công. Đây là một bước ngoặt trong nghiên cứu lỗ hổng — và đồng nghĩa với việc nguồn cung lỗ hổng kernel nghiêm trọng sẽ tăng lên.

Nền tảng Tenbyte Cloud có bị ảnh hưởng không?

Không. Tenbyte Cloud chạy mỗi Cloud Server trong một máy ảo riêng biệt với kernel được cách ly. Copy Fail là khai thác cấp độ kernel — không thể vượt qua ranh giới VM. Một Cloud Server bị xâm nhập không thể tiếp cận hypervisor, không thể truy cập cache trang của host và không thể can thiệp vào máy chủ của khách hàng khác.

Chúng tôi đã xác minh điều này trên toàn bộ hạ tầng. Các host của chúng tôi an toàn.

Những việc chúng tôi đã thực hiện

• Xác minh toàn bộ hệ thống host — xác nhận không có thành phần hạ tầng Tenbyte bị lộ.
• Chuẩn bị mẫu OS cập nhật — khi các bản vá upstream được phát hành, các triển khai mới sẽ mặc định đi kèm kernel đã được vá
• Giám sát các bản phát hành upstream — theo dõi thời gian thực danh sách mailing bảo mật của mọi bản phân phối chính

Những việc bạn cần làm

Các Cloud Server Linux cá nhân của bạn bị ảnh hưởng ở mức OS. Việc vá chúng là trách nhiệm của bạn.

Vá các server của bạn

Lỗ hổng tồn tại trong kernel đang chạy. Việc khởi động lại là bắt buộc — kernel đã được vá phải được tải khi khởi động.

Đánh giá rủi ro: Ai nên xem đây là khẩn cấp

Tất cả hệ thống Linux đều có khả năng bị tấn công. Nhưngrủi ro thực tế phụ thuộc vào mô hình truy cập của bạn.

P1 — Vá trong vòng 24 giờ

• Các server cóngười dùng cục bộ không đáng tin cậy (môi trường shared hosting, đa khách hàng)
• CI/CD runners chạy mã của bên thứ ba (GitHub Actions tự host, GitLab shared runners, Jenkins agents)
• Sandbox thực thi mã AI chạy đầu ra không đáng tin cậy trong container
• Bất kỳ server nào cho phépthực thi mã từ xa bởi người dùng không có quyền

Mã khai thác công khai rất đáng tin cậy và đơn giản. Nếu kẻ tấn công đã có foothold, root chỉ cách một lệnh.

P2 — Vá theo chu kỳ bình thường

• Các server mà chỉquản trị viên đáng tin cậy có quyền truy cập
• Không có đường truyền mã không đáng tin cậy
• Mạng perimter được kiểm soát chặt chẽ

Copy Fail là mộtcấp địa phương nâng quyền, không phải thực thi mã từ xa. Tuy nhiên đừng trì hoãn — hãy vá trong khung thời gian bình thường của bạn.

Phân tích kỹ thuật sâu

Dành cho những ai muốn hiểu cơ chế — không chỉ cách khắc phục.

Cách khai thác hoạt động

1. Kẻ tấn công mở socket AF_ALG bằng giao diệnalgif_aead 
2. Thông quasplice(), dữ liệu được chuyển giữa pipe và giao diện crypto
3. Một lỗi logic trong việc triển khaialgif_aead của kernel gây nó xử lý saisplice() kết thúc — ghi vào vị trí bộ nhớ sai
4. Lệnh ghi sai này rơi vàocache trang của host — cache của kernel chứa nội dung file
5. Bằng cách kiểm soát dữ liệu ghi và vị trí, kẻ tấn công có thể ghi đè các file như/etc/passwd để tạo người dùng root, hoặc chèn khóa SSH vào/root/.ssh/authorized_keys
6. Kẻ tấn công giờ đã có quyền root

Tại sao có thể thoát container

Trên các nền tảng container dùng kernel chung (Kubernetes, Docker, …), cache trang được chia sẻ giữa mọi container trên host. Một tiến trình trong một container có thể ghi đè các file ảnh hưởng tới host và các container khác. Vì vậy các cluster Kubernetes đa khách và CI/CD runners có mức rủi ro cao nhất.

Những gì không bị ảnh hưởng

• Cơ sở hạ tầng dựa trên VM — kernel riêng, cache trang riêng
• MicroVM Firecracker — được sử dụng bởi AWS Lambda và Fargate
• gVisor — kernel ở user-space, không phơi bàyalgif_aead
• Cloudflare Workers — cô lập V8, không có kernel Linux trong mô hình đe dọa
• Máy bare-metal chuyên dụng — đơn khách, không có nguy cơ nhiễm chéo

Mô hình này nhất quán: cách ly bị phá vỡ khi kernel được chia sẻ.

Góc độ AI

Xint Code của Theori đã phát hiện lỗi này trong khoảng một giờ. Để tham khảo, các nhà môi giới zero‑day như Crowdfense trả $10K–$7M cho LPE Linux toàn cầu, đáng tin cậy. Một hệ thống AI đã phát hiện một lỗi trong thời gian ăn trưa.

Điều này không có nghĩa AI thay thế các nhà nghiên cứu bảo mật — đội ngũ Theori là một trong những đội mạnh nhất thế giới (9 lần thắng DEF CON CTF). Nó có nghĩa AI là công cụ tăng sức mạnh, thay đổi kinh tế khám phá lỗ hổng. Các nhà phòng thủ cần thích nghi: chu kỳ vá nhanh hơn, ranh giới cách ly mạnh hơn, và chuẩn bị cho kịch bản bị xâm nhập.

Đọc thêm

• Copy Fail — Công bố chính thức và chi tiết kỹ thuật
• CVE-2026-31431 — Mục nhập MITRE
• Phân tích Bugcrowd — Những gì chúng tôi biết về Copy Fail
• Tài liệu bảo mật Linux Kernel