Một lỗi use-after-free trong mã mạng SCTP của Linux có thể bị khai thác để chiếm quyền root hoàn toàn trên máy chủ. Các nhà nghiên cứu của Tencent cho biết họ đã sử dụng nó để thoát khỏi container và truy cập vào máy vật lý bên dưới.
Lỗ hổng này đã tồn tại từ năm 2008. Bản sửa lỗi hiện đã được phát hành: các phiên bản nhân stable 7.1.6, 6.18.42, 6.12.101 và 6.6.148, ra mắt vào ngày 3 tháng 8, đã khắc phục vấn đề này. Bất kỳ ai đang chạy nhân cũ hơn có thể truy cập SCTP đều nên cập nhật ngay lập tức.
Được theo dõi dưới mã CVE-2026-64564 và được những người phát hiện đặt tên là SCTPhantom, lỗ hổng này đã được công bố công khai vào ngày 6 tháng 8, hai ngày sau khi nhóm kernel CVE chỉ định mã định danh. Tại thời điểm viết bài, chưa có mã khai thác (exploit) công khai nào xuất hiện, và The Hacker News cũng chưa tìm thấy mục nhập nào cho lỗ hổng này trong danh mục Known Exploited Vulnerabilities của CISA tính đến ngày 7 tháng 8.
Lỗ hổng này mang tính cục bộ (local), không phải từ xa (remote), và nó yêu cầu SCTP phải có thể truy cập được trên mục tiêu, điều này giúp hạn chế phạm vi ảnh hưởng. Tại những nơi đáp ứng các điều kiện đó, Tencent Zhuque Lab báo cáo rằng họ đã chiếm được quyền root trên các bản dựng nhân được thử nghiệm cho Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 và OpenCloudOS.
Cơ chế hoạt động của lỗ hổng SCTPhantom
SCTP là một giao thức vận chuyển cho phép một kết nối chạy qua nhiều đường dẫn mạng cùng một lúc. Một tính năng đi kèm là cấu hình lại địa chỉ động (dynamic address reconfiguration), cho phép một bên tham gia thêm hoặc bớt các địa chỉ đó trong quá trình kết nối.
Lỗi này xuất phát từ sự nhầm lẫn về danh tính: kernel kiểm tra yêu cầu xóa dựa trên địa chỉ nguồn của gói tin, nhưng lại thực hiện hành động trên một đường dẫn mà nó đã chọn bằng một địa chỉ khác bên trong thông báo. Theo cố vấn của chính kernel, một thông báo có thể mang theo một địa chỉ, một yêu cầu xóa cho chính địa chỉ đó, sau đó là một yêu cầu xóa bằng ký tự đại diện (wildcard delete). Trình tự đó giải phóng đường dẫn, sau đó sử dụng lại con trỏ đã chết (dead pointer), khiến kết nối trỏ vào vùng bộ nhớ mà kernel đã giải phóng (use-after-free).
Bản vá sẽ từ chối yêu cầu xóa nhắm vào đường dẫn mà thông báo đang được xử lý. Lỗi này bắt nguồn từ phiên bản Linux 2.6.25 vào năm 2008 và đã tồn tại trong mọi nhân được phát hành kể từ đó.
Khả năng thoát khỏi container
Khẳng định về việc thoát khỏi container của Tencent dựa trên các thử nghiệm riêng của họ. Trong bài phân tích của mình, phòng thí nghiệm cho biết một phiên bản sớm của mã khai thác (exploit) cần các sysctls net.sctp.addip_enable và net.sctp.addip_noauth_enable được bật, điều này khiến CAP_NET_ADMIN trở thành một điều kiện tiên quyết. Tuy nhiên, sau đó họ đã tìm ra một lộ trình khác không cần chạm đến hai cấu hình này bằng cách bật các tính năng cho mỗi socket (ổ cắm) thay thế.
Phòng thí nghiệm cho biết thử nghiệm thoát khỏi container của họ vẫn giữ nguyên hồ sơ seccomp mặc định và không cấp quyền CAP_NET_ADMIN hay CAP_SYS_ADMIN. Theo thống kê, 6 trên 8 lần thử nghiệm đã chiếm được quyền root trên máy chủ host.
Chưa có bên nào ngoài phòng thí nghiệm này tái lập được kết quả đó, và bài phân tích không nêu tên runtime của container mà họ đã thử nghiệm. Bản thân phòng thí nghiệm lưu ý rằng việc truy cập socket, hồ sơ seccomp và chính sách không gian tên người dùng (user-namespace) đều làm thay đổi mức độ rủi ro. Một cố vấn từ openKylin về cùng lỗi này cho rằng nó chỉ dừng lại ở mức gây kernel panic và tấn công từ chối dịch vụ (denial of service).
Mức độ nghiêm trọng và khuyến nghị cập nhật
Chỉ số mức độ nghiêm trọng hiện vẫn chưa thống nhất. Tencent chấm điểm lỗ hổng này là 8.5 theo CVSS v4.0. Tính đến ngày 7 tháng 8, NVD vẫn chưa chỉ định điểm số hay phân loại điểm yếu.
Các nhà cung cấp thường đưa các bản sửa lỗi (backport) vào các phiên bản cũ mà không chuyển sang phiên bản thượng nguồn (upstream) mới, vì vậy chỉ riêng chuỗi phiên bản nhân có thể không cho bạn biết liệu bạn đã được bảo vệ hay chưa; hãy kiểm tra trình theo dõi của bản phân phối bạn đang dùng. Một lỗi use-after-free thứ hai liên quan đến vận chuyển bị treo (dangling-transport) trong cùng một mã nguồn đã được vá vào ngày 6 tháng 8, sau khi các bản phát hành stable ngày 3 tháng 8 được xuất xưởng, vì vậy các nhân đó không chứa bản vá này. Ở những nơi không cần SCTP, việc chặn module này sẽ loại bỏ hoàn toàn bề mặt tấn công.
Tencent ghi nhận phát hiện này nhờ Corvus AI, một hệ thống nghiên cứu đa tác nhân mà họ xây dựng cho công việc tìm lỗi kernel. SCTPhantom là lỗ hổng mới nhất trong chuỗi các lỗi kernel ngủ yên từ lâu được đưa ra ánh sáng với sự hỗ trợ của máy móc trong năm nay, cùng với GhostLock vào tháng 7. Nó cũng xuất hiện cùng ngày với Zapscape, một lỗi thoát KVM không liên quan, và cả bốn bản phát hành stable nói trên đều chứa cả hai bản sửa lỗi.
