Lỗ hổng TCP của Linux được nâng lên 9,8 điểm CVSS

Ngày 2/11, Red Hat nâng điểm CVSS của lỗ hổng nhân Linux CVE-2026-98432 lên 9,8, sau khi trước đó đã chấm trong khoảng từ 5,9 đến 8,1. Hãng đã phát hành nhân đã vá cho RHEL 8, 9 và 10 vào ngày 1/11. Trạng thái của Ubuntu vẫn là đang vá.

Lỗ hổng nằm trong quy trình thiết lập kết nối TCP trên IPv4, có thể kích hoạt từ phía mạng mà không cần xác thực hay thao tác nào của người dùng. Phạm vi ảnh hưởng tính từ Linux 4.4, và nguyên nhân gốc truy ngược về một commit năm 2015.

Điều kiện tranh chấp được vá bằng hai dòng mã

Khi gói SYN mang các tùy chọn IPv4 (chẳng hạn Record Route hay Timestamp), nhân lưu chúng trên socket yêu cầu. Khi bắt tay hoàn tất, con trỏ tới vùng nhớ này được trao thẳng cho socket con mà không sao chép, nên hai bên dùng chung một bản.

Nếu lúc đó một CPU khác đang dựng SYN-ACK cho một gói SYN được gửi lại, và socket con vừa bị hủy, vùng nhớ tùy chọn sẽ bị kfree() giải phóng ngay. Đường dựng SYN-ACK khi ấy đọc phải vùng nhớ đã được giải phóng.

Bản vá do Eric Dumazet gửi, commit e3f33b0a1d89, thay kfree() bằng kfree_rcu() để chờ hết thời gian ân hạn RCU rồi mới giải phóng, chỉ sửa hai dòng. Người báo cáo lỗ hổng là Xinyang Ge của Anthropic. Bản ghi CVE được công bố ngày 15/10; các phiên bản sửa lỗi trên nhánh ổn định là 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 và 7.2.10, còn nhánh chính là 7.3.

Lời của Anthropic chỉ chính họ mới chứng minh được

Điều khiến lỗ hổng được chú ý là một bài viết của Anthropic Frontier Red Team ngày 27/10. Bài viết cho biết một mô hình nội bộ chưa phát hành đã viết cho họ một chương trình khai thác, cho phép kẻ tấn công từ xa chưa xác thực chạy lệnh với quyền root trên máy chủ đang bật lắng nghe MPTCP.

Việc khai thác chia làm hai giai đoạn: trước hết dùng điều kiện tranh chấp để đọc vượt biên bộ nhớ nhân, làm lộ con trỏ và vượt KASLR; sau đó dùng thao tác ghi vượt biên để ghi đè con trỏ hàm gọi lại. Anthropic đưa ra thời gian khoảng 48 phút để làm lộ con trỏ, rồi thêm khoảng 5 phút nữa để thực thi lệnh.

Có mấy điểm cần tách bạch. Mã khai thác, phiên bản nhân dùng để thử và cấu hình đều chưa được công bố, và hiện chưa có bên thứ ba nào kiểm chứng. Bản ghi CVE và commit sửa lỗi đều không nhắc tới MPTCP, bài viết cũng không giải thích vì sao bắt buộc phải có nó. Con số 53 phút là kết quả trong một môi trường không rõ, không thể áp thẳng cho máy chủ đang vận hành. Tính đến ngày 2/11, chưa có nhà cung cấp, CERT hay nhóm CVE của nhân báo cáo việc khai thác ngoài thực tế, và danh mục các lỗ hổng đã bị khai thác của CISA cũng chưa đưa nó vào.

Một số bài lan truyền bằng tiếng Trung viết rằng “Anthropic đã công bố ví dụ khai thác”. Chính xác hơn, họ chỉ công bố phần mô tả quá trình khai thác, chứ không phát hành mã chạy được.

Bất đồng về điểm số cũng vẫn còn. Nhóm CVE của nhân Linux và Red Hat hiện chấm 9,8, trong khi Oracle, SUSE và Amazon chấm 8,1; khác biệt nằm ở chỗ độ phức tạp tấn công được đánh giá là thấp hay cao. NVD vẫn chưa đưa ra điểm riêng.

Go biến điều kiện tiên quyết thành giá trị mặc định

Thông báo của nhóm bảo mật Go ngày 29/10 làm phạm vi ảnh hưởng rộng thêm. Từ Go 1.24, giá trị mặc định của multipathtcp là 2, nghĩa là chỉ bật MPTCP ở phía lắng nghe. Nói cách khác, chương trình Go dựng dịch vụ bằng net.Listen mặc định đã thỏa điều kiện tiên quyết mà Anthropic trình diễn.

Biện pháp giảm thiểu nhóm Go đưa ra là đặt GODEBUG=multipathtcp=0 khi chạy, hoặc ghi godebug multipathtcp=0 trong go.mod của module chính. Nhóm này đồng thời gọi cách tắt theo từng chương trình là "a fragile mitigation" (một biện pháp giảm thiểu mong manh). Theo nhóm Go, việc đổi giá trị mặc định lúc này là quá sớm. Về phía nhân, có thể đặt net.mptcp.enabled bằng 0; cách này chỉ loại bỏ điều kiện tiên quyết đã được trình diễn, còn bản thân lỗ hổng vẫn còn đó.

Quản trị viên có thể làm gì trước

Trạng thái của các bản phân phối (một phần kiểm tra ngày 29/10, một phần ngày 2/11) đại thể như sau:

Ubuntu chiếm tỷ lệ không nhỏ trong số người dùng máy chủ đám mây, nên đây là dòng trong bảng cần theo dõi sát nhất. Các bản phân phối phần lớn vá bằng cách đưa bản vá về các nhánh cũ (backport), vì vậy muốn biết đã vá hay chưa phải đối chiếu phiên bản gói trong thông báo bảo mật của chính bản phân phối đó; chỉ nhìn số phiên bản chính trong uname -r rất dễ nhầm. Cài nhân mới xong phải khởi động lại, còn vá nóng là một cơ chế khác, cần xác nhận riêng.

Với những máy tạm thời chưa có bản vá, trước hết có thể kiểm kê các dịch vụ đang lắng nghe MPTCP, nhất là các tệp nhị phân biên dịch bằng Go 1.24 trở lên, rồi quyết định có tắt theo cách nêu trên hay không. Các nhà cung cấp chưa xác nhận rằng tắt MPTCP loại bỏ được toàn bộ rủi ro, nên bước này chỉ có tác dụng câu thêm thời gian. Nếu nhật ký lỗi nhân xuất hiện các hàm như ip_options_build, cũng nên kiểm tra.

Nguồn tham khảo: các bản thuật lại công khai bài viết của Anthropic Frontier Red Team, thông báo lỗ hổng của Rescana, CocoLoop, thông báo của nhóm bảo mật Go, các trang theo dõi bảo mật của Debian và Red Hat; điểm số và trạng thái sửa lỗi của từng bản phân phối theo công bố của các nhà cung cấp, chi tiết khai thác của Anthropic chưa được kiểm chứng độc lập.