CVE-2026-31431: Biệt danh copy fail và một bài học về lỗ hổng logic trong Linux kernel

Trong giai đoạn 2025 đến 2026, số lượng lỗ hổng liên quan đến Linux kernel tăng mạnh. Khi kernel trở thành một phần trung tâm của máy chủ, container, cloud workload và hạ tầng CI/CD, mỗi lỗ hổng leo quyền cục bộ đều có thể trở thành mắt xích quan trọng trong chuỗi tấn công.

Một kịch bản phổ biến là attacker xâm nhập ban đầu bằng tài khoản yếu, lỗ hổng web, credential rò rỉ hoặc phishing. Sau đó, attacker sử dụng kernel exploit để chuyển từ user thường sang quyền root. Khi đã có quyền root, attacker có thể cài persistence, truy cập dữ liệu nhạy cảm, tắt cơ chế giám sát hoặc di chuyển sang hệ thống khác.

Copy Fail đáng chú ý vì cùng một nguyên lý có thể ảnh hưởng đến nhiều bản phân phối Linux lớn. Nếu một lỗ hổng có độ ổn định cao, ít phụ thuộc vào race condition và không cần điều chỉnh phức tạp theo từng môi trường, rủi ro vận hành sẽ tăng lên rõ rệt.

2. Bản chất kỹ thuật

Copy Fail có thể được hiểu là một lỗi logic trong cách Linux kernel xử lý một số đường đi liên quan đến crypto, page cache và thao tác truyền dữ liệu kiểu zero copy. Vấn đề không xuất phát từ một lỗi đơn lẻ dễ nhìn thấy. Nó xuất hiện khi nhiều thành phần hợp lệ được ghép lại trong cùng một luồng xử lý.

2.1. AF_ALG

AF_ALG là cơ chế cho phép chương trình ở user space sử dụng các thuật toán mật mã do kernel cung cấp. Về mặt thiết kế, cơ chế này giúp ứng dụng gọi các primitive mật mã như hash, encryption hoặc AEAD thông qua socket interface.

Vấn đề bảo mật phát sinh khi một interface mạnh như vậy có thể được tiếp cận từ user space. Một thành phần vốn được thiết kế để hỗ trợ hiệu năng có thể trở thành attack surface nếu các đường đi nội bộ không được kiểm soát chặt chẽ.

2.2. splice và zero copy

splice() cho phép truyền dữ liệu giữa file descriptor mà không cần copy dữ liệu qua user space. Cơ chế này giúp tăng hiệu năng vì kernel có thể truyền tham chiếu đến page trong page cache thay vì sao chép từng byte.

Page cache là vùng nhớ mà kernel dùng để lưu nội dung file đã đọc gần đây. Khi một binary như /usr/bin/su được đọc hoặc thực thi, nội dung liên quan có thể tồn tại trong page cache. Nếu một đường đi nào đó làm thay đổi page cache mà không ghi xuống đĩa, file trên disk vẫn có thể giữ nguyên, nhưng nội dung kernel sử dụng tại thời điểm thực thi có thể đã khác.

2.3. authencesn

authencesn là một template AEAD được thiết kế cho các nhu cầu liên quan đến IPsec và Extended Sequence Numbers. Cơ chế này xử lý đồng thời mã hóa và xác thực dữ liệu. Trong một số đường đi, buffer đầu vào và đầu ra có thể được xử lý theo kiểu in place.

Khi in place processing được kết hợp với dữ liệu đi qua AF_ALG và splice(), kernel có thể thao tác trên các page có nguồn gốc từ page cache. Nếu đường đi này không phân biệt rõ page nào được phép ghi và page nào chỉ nên đọc, lỗi logic có thể dẫn đến việc ghi ngoài dự kiến vào page cache của file.

3. Chuỗi tác động

Khi attacker có thể tác động đến page cache của một binary có quyền cao, họ không nhất thiết phải sửa file trên đĩa. Kernel có thể nạp nội dung đã bị thay đổi trong RAM khi binary được thực thi. Điều này tạo ra rủi ro leo quyền cục bộ.

Điểm quan trọng ở đây là sự khác biệt giữa disk state và memory state. Disk state có thể vẫn sạch. Hash của file trên đĩa có thể không đổi. Công cụ giám sát integrity truyền thống có thể không phát hiện bất thường. Tuy nhiên, memory state mà kernel sử dụng có thể đã bị thay đổi.

Luồng khái quát của vấn đề có thể được mô tả như sau:

User thường gọi AF_ALG. Dữ liệu từ file được đưa vào đường xử lý thông qua splice(). Kernel xử lý AEAD theo kiểu in place. Một phần page cache của file chỉ đọc bị tác động ngoài dự kiến. Khi binary được nạp lại, kernel có thể sử dụng nội dung đã bị thay đổi trong RAM.

4. So sánh với một số lỗ hổng kernel nổi tiếng

Copy Fail thường được đặt cạnh các lỗ hổng như Dirty COW và Dirty Pipe vì cả ba đều liên quan đến cách kernel quản lý dữ liệu, bộ nhớ và file. Tuy nhiên, điểm khác biệt nằm ở độ ổn định và mức phụ thuộc vào điều kiện môi trường.

Bảng trên cho thấy Copy Fail phù hợp để đưa vào bài học về logic bug. Sinh viên không chỉ học một lỗi cụ thể, mà còn học cách đặt câu hỏi về tương tác giữa các thành phần. Trong security review, các thành phần an toàn khi đứng riêng vẫn cần được đánh giá lại khi được ghép với nhau.

5. Tác động đối với điều tra số

Điểm khó của loại lỗ hổng này là dấu vết có thể không nằm trên đĩa. Nếu file trên disk không bị thay đổi, các biện pháp kiểm tra như hash baseline, file integrity monitoring hoặc so sánh disk image có thể không đủ.

Trong tình huống nghi ngờ bị khai thác, memory acquisition cần được ưu tiên trước khi reboot. Nếu hệ thống bị khởi động lại, page cache có thể bị xóa và bằng chứng quan trọng có thể mất. Điều này làm thay đổi thứ tự xử lý sự cố. Đối với incident response, RAM snapshot, eBPF telemetry, runtime tracing và log hành vi hệ thống trở nên quan trọng hơn.

Bài học ở đây rất rõ. Với các lỗ hổng chỉ tác động đến trạng thái trong RAM, điều tra dựa trên disk image là chưa đủ. Nhóm phòng thủ cần có quy trình thu thập memory, giám sát syscall và phát hiện hành vi bất thường tại runtime.

6. Tác động đối với container

Container có namespace riêng cho process, network và mount. Tuy nhiên, nhiều tài nguyên kernel vẫn được chia sẻ ở mức host, trong đó có page cache. Đây là đặc điểm thiết kế nhằm tiết kiệm bộ nhớ và tăng hiệu năng.

Nếu một workload trong container có thể kích hoạt đường đi lỗi trong kernel, ranh giới container có thể bị ảnh hưởng. Vấn đề không nằm ở container runtime đơn thuần, mà nằm ở việc container vẫn dùng chung kernel với host. Vì vậy, một lỗ hổng kernel có thể trở thành nền tảng cho container escape nếu có điều kiện phù hợp.

Trong môi trường Kubernetes, rủi ro này cần được đánh giá nghiêm túc. Các node chạy workload không tin cậy, CI runner, sandbox build hoặc môi trường thực hành an ninh mạng cần chính sách syscall chặt hơn so với workload nội bộ có độ tin cậy cao.

7. Giảm thiểu rủi ro

7.1. Cập nhật kernel

Biện pháp quan trọng nhất là cập nhật kernel theo bản vá của nhà cung cấp. Khi lỗ hổng nằm trong kernel, các biện pháp ở tầng ứng dụng chỉ có giá trị giảm thiểu. Chúng không thay thế được bản vá.

7.2. Giới hạn AF_ALG trong môi trường không cần thiết

Nếu workload không cần dùng AF_ALG, có thể xem xét chặn hoặc giới hạn interface này bằng seccomp, AppArmor, SELinux hoặc chính sách runtime tương đương. Với container và CI runner, chính sách mặc định nên theo hướng chỉ cho phép syscall cần thiết.

# Ví dụ cấu hình giảm thiểu tạm thời
# Chỉ áp dụng sau khi đã kiểm thử trên môi trường staging

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

Cấu hình trên chỉ nên được xem như biện pháp tạm thời. Trước khi triển khai diện rộng, cần kiểm tra ảnh hưởng đến workload hợp lệ, đặc biệt là hệ thống có dùng crypto kernel acceleration.

7.3. Giám sát runtime

Nhóm phòng thủ nên giám sát các hành vi bất thường liên quan đến AF_ALG, splice() và process không thường xuyên dùng crypto socket. Một số công cụ như Falco, Sysdig hoặc eBPF based tracing có thể hỗ trợ phát hiện hành vi này ở runtime.

7.4. Tăng cường chính sách cho Kubernetes node

Đối với Kubernetes, cần rà soát seccomp profile, quyền của pod, khả năng load module và quyền truy cập các interface kernel nhạy cảm. Workload không tin cậy cần được chạy trên node tách biệt, có policy hạn chế hơn và có telemetry đầy đủ hơn.

8. Dòng thời gian khái quát

9. Bài học cho sinh viên An toàn thông tin

Bài học thứ nhất là lỗ hổng nguy hiểm không nhất thiết phải phức tạp ở bề mặt. Nhiều lỗ hổng nghiêm trọng xuất hiện từ tương tác giữa các thành phần hợp lệ. Vì vậy, threat modeling không thể chỉ hỏi từng module có an toàn không. Nó phải hỏi dữ liệu đi qua các module như thế nào, quyền ghi đọc thay đổi ra sao và ranh giới tin cậy bị dịch chuyển ở điểm nào.

Bài học thứ hai là tối ưu hóa hiệu năng luôn cần được đánh giá lại dưới góc nhìn bảo mật. Các kỹ thuật như zero copy, in place processing hoặc shared cache đều có giá trị hiệu năng rõ ràng. Tuy nhiên, chúng cũng làm giảm một số lớp cách ly tự nhiên. Khi dữ liệu không còn được copy sang buffer riêng, quyền sở hữu và quyền ghi của vùng nhớ cần được kiểm soát cẩn thận hơn.

Bài học thứ ba là nghiên cứu lỗ hổng hiện đại đang thay đổi. AI assisted scanning có thể giúp rà soát codebase lớn, nhưng phát hiện có giá trị vẫn cần tri thức con người để đặt câu hỏi đúng, kiểm chứng đúng và hiểu tác động thực tế. Sinh viên An toàn thông tin cần học cả kỹ thuật kernel, secure coding, threat modeling và cách dùng AI như một công cụ hỗ trợ nghiên cứu có kiểm soát.

Bài học thứ tư là phòng thủ phải chuyển từ kiểm tra tĩnh sang quan sát runtime. Nếu một lỗ hổng không để lại thay đổi trên đĩa, hệ thống phòng thủ không thể chỉ dựa vào hash file hoặc kiểm tra integrity định kỳ. Cần có telemetry ở tầng syscall, process, container runtime và kernel behavior.

Kết luận

Copy Fail là một ví dụ tốt để giảng dạy về lỗ hổng logic trong kernel. Nó cho thấy bảo mật không chỉ nằm ở từng hàm riêng lẻ. Bảo mật còn nằm ở cách các hàm, subsystem và cơ chế tối ưu hóa tương tác với nhau trong cùng một đường đi dữ liệu.

Đối với người làm phòng thủ, bài học thực tế là phải cập nhật kernel sớm, giới hạn attack surface không cần thiết, giám sát runtime và chuẩn bị quy trình thu thập memory khi có sự cố. Đối với sinh viên, bài học quan trọng hơn là cách tư duy. Khi đánh giá một hệ thống, cần nhìn vào ranh giới tin cậy, quyền sở hữu dữ liệu và các tương tác có thể tạo ra hành vi ngoài thiết kế.