CVE-2026-98432: Lỗ hổng TCP nghiêm trọng trong Linux cho phép kẻ tấn công từ xa chiếm quyền root

Nhân Linux vừa phát hành bản vá cho CVE-2026-98432, một lỗ hổng use-after-free trong quá trình bắt tay IPv4 TCP mà bất kỳ đối tượng từ xa nào cũng có thể chạm tới mà không cần thông tin xác thực. Tổ chức CNA của nhân Linux chấm lỗ hổng này CVSS 3.1 là 9.8 — mức Nghiêm trọng (Critical).

Điểm đáng lo ngại là dù bản sửa lỗi đã có từ giữa tháng 10/2026, nhiều bản phân phối Linux phổ biến vẫn chưa phát hành bản vá. Theo ghi nhận lúc 20h00 ngày 29/10/2026 (giờ CDT), bộ theo dõi của Ubuntu vẫn đánh dấu "Vulnerable" cho nhân trên mọi phiên bản, còn Red Hat liệt kê RHEL 8, 9 và 10 là bị ảnh hưởng mà chưa có bản sửa.

Lỗ hổng nằm ở đâu và nguy hiểm thế nào?

Khi một máy chủ Linux chấp nhận kết nối TCP, nhân hệ điều hành sẽ theo dõi trạng thái bắt tay dở dang trong một "request socket" nhẹ, sau đó tạo socket đầy đủ khi quá trình hoàn tất. Nếu gói tin của bên kết nối có chứa các tùy chọn IPv4 (IPv4 options), nhân sẽ lưu lại để phản hồi trong các gói trả lời.

Lỗi xảy ra ở chỗ: nhân chuyển các tùy chọn đã lưu từ request socket sang kết nối mới mà không sao chép, rồi giải phóng vùng nhớ đó ngay khi kết nối kết thúc — trong khi một CPU khác vẫn có thể đang đọc dữ liệu này để tạo phản hồi bắt tay. Đọc vùng nhớ đã bị giải phóng chính là một lỗ hổng use-after-free.

Toàn bộ quá trình diễn ra bên trong phần xử lý bắt tay của nhân, trước khi bất kỳ mã ứng dụng nào chạy. Theo ghi chú chấm điểm của CNA, dữ liệu cũ có thể làm rò rỉ nội dung bộ nhớ heap của nhân về phía đối tượng từ xa, dẫn việc ghi bộ nhớ nhân ra ngoài phạm vi, hoặc làm sập máy chủ.

Red Hat mô tả: lỗi "chủ yếu dẫn đến sập hệ thống gây từ chối dịch vụ (DoS) hoặc có khả năng làm hỏng bộ nhớ".

Anthropic — đơn vị có nhà nghiên cứu phát hiện ra lỗi — cho biết mô hình Claude đã tự viết được một mã khai thác PoC hoạt động thực tế, chạy lệnh với quyền root trên "các máy chủ Linux có listener Multipath TCP", không cần thông tin xác thực. Họ cũng lưu ý rằng nếu một lần thử thua "cuộc đua" thì chỉ thất bại ở bước bắt tay chứ không làm sập cả hệ thống, nên kẻ tấn công kiên trì có thể thử lại vô hạn cho đến khi thành công.

Những ai đang bị ảnh hưởng?

Mọi nhân Linux từ phiên bản 4.4 trở đi mà chưa có bản vá đều bị ảnh hưởng, bất kể máy đó trực tiếp phục vụ mạng hay chạy container. Cần lưu ý: container chạy trên nhân của máy chủ, nên việc cập nhật image container không giải quyết được gì.

Các phiên bản đã có bản sửa lỗi chính thức:

• 7.2.10 và 6.18.56 (11/10/2026)
• 6.12.113, 6.6.159, 6.1.190, 5.15.223, 5.10.272 (15/10/2026)
• 7.3 (18/10/2026)

Các nhánh upstream đã hết hỗ trợ (EOL) trước 5.10 sẽ không nhận được bản vá. Kết nối IPv6 không bị ảnh hưởng bởi vấn đề chính.

Tình trạng các bản phân phối (tính đến 29/10/2026)

Các bản phân phối thường mang bản vá dưới số phiên bản riêng của họ, nên cần kiểm tra bộ theo dõi của từng hãng chứ không chỉ nhìn số phiên bản upstream.

• Ubuntu: bộ theo dõi đánh dấu gói linux là "Vulnerable" trên mọi phiên bản. Trên 26.10, 26.04, 24.04 và 22.04 có thêm ghi chú "đang xử lý" với các phiên bản 7.3.0-10.10, 7.0.0-43.43, 6.8.0-149.149 và 5.15.0-203.213; các bản 20.04, 18.04, 16.04 chỉ hiển thị "Vulnerable". Chưa có Thông báo Bảo mật Ubuntu (USN) nào được phát hành.
• Red Hat: RHEL 8, 9, 10 và OpenShift Container Platform 4 bị ảnh hưởng, chưa có bản sửa. RHEL 6 và 7 không bị ảnh hưởng. Red Hat cho biết không có biện pháp giảm thiểu nào đáp ứng tiêu chí của họ.
• Debian: đã sửa trong 12 "bookworm" (6.1.190-1, DLA-4841-1 và linux-6.12 6.12.113-1~deb12u1, DLA-4850-1), 13 "trixie" (6.12.113-1, DSA-6568-1) và nhánh unstable.
• SUSE: mức quan trọng. SUSE Linux Enterprise Server 16.0 và các nhân LTSS 15 SP4, SP5, SP6 đã được sửa; 15 SP7 đang xử lý; openSUSE Leap 15.6 và 16.0 vẫn bị ảnh hưởng.
• Oracle Linux: mức Important, CVSS 8.1. Bản vá cho nhân UEK của Oracle Linux 7, 8, 9, 10 đã ra ngày 16/10 (ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399).
• Amazon Linux: mức Important, CVSS 8.1. Trên Amazon Linux 2023, kernel6.18 đã được sửa (24/10) và kernel6.12 đã được sửa (29/10). Gói kernel mặc định và toàn bộ nhân của Amazon Linux 2 vẫn "Pending Fix".

Bản sửa lỗi chỉ gồm bốn dòng thay đổi

Bản vá của Eric Dumazet, có tên "ipv4: free inet_opt and ireq_opt after an RCU grace period", thay hai lệnh gọi kfree() đơn giản bằng kfree_rcu() — hàm này chờ đến khi mọi tiến trình đọc đã dùng xong vùng nhớ rồi mới giải phóng. Các đoạn mã khác vốn đã làm như vậy khi thay thế các tùy chọn này.

Bản sửa cũng khắc phục vấn đề tương tự trong cơ chế di chuyển request socket (net.ipv4.tcp_migrate_req=1) và cho biết trường hợp IPv6 liên quan "sẽ được xử lý trong một bản vá riêng".

Cách kiểm tra hệ thống của bạn

Kiểm tra nhân

uname -r                             # nhân đang chạy
uname -v                             # Debian: phiên bản gói đang chạy
dpkg -l 'linux-image*' | grep ^ii    # Debian/Ubuntu: các gói nhân đã cài
rpm -q kernel                        # RHEL và các bản dẫn xuất
needs-restarting -r                  # RHEL (dnf-utils): có cần khởi động lại?

Hãy so kết quả với trạng thái của bản phân phối chứ không phải với số phiên bản upstream. Nếu nhân đã cài mới hơn nhân đang chạy, bản vá chưa có hiệu lực cho đến khi khởi động lại. Chạy các lệnh này trên máy chủ và node Kubernetes, không chạy trong container — vì container báo cáo nhân của máy chủ.

Kiểm tra listener Multipath TCP

ss -Mlnp                   # các socket MPTCP đang lắng nghe và tiến trình sở hữu
sysctl net.mptcp.enabled   # 1 nghĩa là ứng dụng có thể mở socket MPTCP

Lệnh ss -M chỉ liệt kê socket MPTCP, nên kết quả rỗng nghĩa là không có listener MPTCP. Việc net.mptcp.enabled = 1 tự nó không tạo ra listener — phải có ứng dụng chủ động mở socket MPTCP.

Cách khắc phục

Cập nhật nhân và khởi động lại

Cài bản nhân đã vá của bản phân phối ngay khi có, rồi khởi động lại máy: bản cập nhật nhân không có hiệu lực cho đến khi máy khởi động vào nhân mới. Đừng quên khởi động lại cả máy chủ container và node Kubernetes. Các thiết bị chuyên dụng và image cloud có sẵn nhân cần bản cập nhật từ nhà cung cấp.

Nếu chưa thể vá ngay

Red Hat không đưa ra biện pháp giảm thiểu nào. Dưới đây là khuyến nghị tạm thời dựa trên ghi chú chấm điểm của CNA, vốn cho biết bên tấn công cung cấp tùy chọn IPv4 Record Route hoặc Timestamp trong gói SYN. Lưu lượng TCP hầu như không bao giờ mang tùy chọn IPv4 một cách hợp lệ, nên việc loại bỏ các gói như vậy gần như không gây ảnh hưởng:

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

Quy tắc ip hdrlength gt 5 khớp với mọi header IPv4 dài hơn mức tối thiểu 20 byte — điều chỉ xảy ra khi có tùy chọn. Quy tắc này chạy trước connection tracking, không đụng đến IPv6 hay lưu lượng không phải TCP. Lưu ý: đây không phải bản sửa lỗi, và nó chỉ tồn tại đến khi khởi động lại. Nếu tường lửa biên của bạn có thể loại bỏ gói IPv4 có tùy chọn, hãy làm ở đó để bảo vệ mọi máy phía sau.

Trong thời gian chờ đợi, hãy giữ các listener MPTCP tách khỏi Internet và đưa những máy có listener như vậy lên đầu danh sách cần vá.

Mối lo ngại về AI tạo mã khai thác

Câu chuyện đáng chú ý không chỉ nằm ở lỗ hổng. Anthropic cho biết Claude viết được mã khai thác "sau lần nhắc ban đầu", chạy "lệnh tùy ý với quyền root, không cần thông tin xác thực hay tương tác người dùng", và trong PoC của họ, "mất 48 phút để rò rỉ một con trỏ nhân và thêm 5 phút nữa để đạt được thực thi lệnh shell". Anthropic chưa công bố mã khai thác.

Tính đến 20h00 ngày 29/10, đã có 8 kho lưu trữ GitHub tham chiếu đến CVE này, phần lớn tự mô tả là công cụ kiểm tra hoặc giảm thiểu — trong đó có một Ansible role và một livepatch cho AlmaLinux, Rocky Linux. Một kho được tạo lúc 19h22 cho biết có chứa "race trigger". CVE này chưa nằm trong danh mục Known Exploited Vulnerabilities của CISA.

Đây cũng là bản vá nhân Linux thứ hai trong tháng chỉ có hiệu lực sau khi khởi động lại — bản còn lại là Fragnesia, đang được nối chuỗi với PHP2Shell để chiếm quyền root.

Lời khuyên cho người dùng tại Việt Nam

Với các doanh nghiệp và cá nhân vận hành máy chủ Linux — đặc biệt là hệ thống VPS, máy chủ web, hay cụm Kubernetes trên các nhà cung cấp cloud — nên chủ động:

• Kiểm tra ngay phiên bản nhân và theo dõi bộ theo dõi bảo mật của nhà cung cấp
• Khởi động lại là bước bắt buộc, không thể bỏ qua sau khi cập nhật
• Rà soát xem có ứng dụng nào đang dùng Multipath TCP hay không
• Áp dụng quy tắc tường lửa tạm thời nếu chưa có bản vá, đặc biệt với máy chủ lộ diện trực tiếp ra Internet

Với các hệ thống dùng nhân tùy chỉnh hoặc bản phân phối không còn được hỗ trợ, cần lên kế hoạch nâng cấp lên nhánh còn được hỗ trợ — vì các nhánh EOL sẽ không bao giờ nhận được bản vá này.