CVE-2026-98432: Lỗi kernel Linux 9.8 — AI viết exploit root trong 53 phút, Ubuntu và RHEL vẫn chưa có bản vá

Ngày 27/10/2026, Anthropic công bố một mô hình AI nghiên cứu nội bộ của họ đã tự viết được exploit khai thác lỗi kernel Linux để chạy lệnh với quyền root mà không cần đăng nhập. Hai ngày sau, The Hacker News tổng hợp toàn cảnh: lỗi này mang mã CVE-2026-98432, được nhóm CVE của kernel Linux chấm 9.8/10, nhưng tới 29/10 thì Ubuntu và Red Hat Enterprise Linux (RHEL) vẫn chưa phát hành kernel đã vá. Nếu bạn đang chạy VPS, máy chủ web hay cụm Kubernetes trên Linux, đây là bài bạn cần đọc ngay hôm nay — và quan trọng không kém: có vài điểm trong câu chuyện này đang bị thổi phồng, mình sẽ chỉ rõ đâu là sự thật đã xác thực, đâu là tuyên bố chưa có bằng chứng độc lập.

1. Chuyện gì đã xảy ra?

Mọi chuyện diễn ra rất nhanh trong vòng chưa đầy một tháng:

Mốc thời gian	Sự kiện
05/10/2026	Các nhà phát triển kernel áp dụng bản sửa upstream, chuyển từ kfree() sang kfree_rcu() ở hai hàm xử lý socket TCP
15/10/2026	CVE-2026-98432 được công bố trên hồ sơ CVE, kèm mô tả kỹ thuật của lỗi
24/10/2026	Nhóm CVE của kernel bổ sung điểm CVSS 9.8 (Critical) vào hồ sơ
27/10/2026	Anthropic đăng bài nghiên cứu: mô hình Claude nội bộ đã viết exploit root cho lỗi này trong 53 phút
29/10/2026	The Hacker News tổng hợp tình trạng vá của các distro: Debian, Oracle Linux, SUSE và Amazon Linux đã có bản vá; Ubuntu và RHEL thì chưa

Điểm đáng chú ý: bản sửa upstream đã có từ 05/10, trước khi CVE công bố tới 10 ngày. Nhưng bạn không dùng kernel “trần” từ kernel.org — bạn dùng kernel do distro đóng gói, và ở khâu đóng gói này tốc độ các distro chênh nhau tới vài tuần. “Đã có bản vá upstream” không đồng nghĩa với “máy chủ của bạn đã an toàn”.

2. Lỗi nằm ở đâu trong kernel?

2.1. Bắt tay TCP và một cuộc đua giữa hai CPU

Khi máy chủ nhận gói SYN (gói “xin kết nối” đầu tiên), kernel tạo một “request socket” — bản ghi tạm chờ hoàn tất bắt tay ba bước. Khi bắt tay xong, hàm tcp_v4_syn_recv_sock() tạo socket con thật sự và chuyển quyền sở hữu khối tùy chọn IP (ireq->ireq_opt) từ request socket sang socket con — mà không sao chép nó.

Vấn đề: từ commit 079096f103fa, các request socket được xử lý mà không giữ khóa của listener, nên hoàn toàn có thể xảy ra kịch bản sau:

1. CPU thứ nhất hoàn tất bắt tay, tạo socket con, rồi socket con đó bị hủy — kernel giải phóng ireq_opt bằng kfree() thông thường.
2. Cùng lúc đó, CPU thứ hai đang xử lý một gói SYN gửi lại (retransmitted SYN) cho cùng request socket đó, và vẫn đang đọc ireq_opt để dựng gói SYNACK trả lời.
3. Kết quả: kernel đọc vào vùng nhớ vừa bị giải phóng — lỗi use-after-free ngay trong ip_options_build(), tức là ngay trên đường đi của gần như mọi kết nối TCP IPv4.

2.2. Bản sửa chỉ là một thay đổi nhỏ nhưng đúng chỗ

Bản sửa upstream không viết lại cả hệ thống TCP. Nó chỉ thay kfree() bằng kfree_rcu() trong hai hàm inet_sock_destruct() và tcp_v4_reqsk_destructor(): thay vì giải phóng vùng nhớ ngay lập tức, kernel chờ qua một “giai đoạn ân hạn RCU” — chỉ giải phóng khi chắc chắn không còn CPU nào đang đọc nó nữa. Cách này nhất quán với phần còn lại của mã nguồn, vì các đường đọc vốn đã dùng RCU.

Cũng theo hồ sơ CVE, có hai chi tiết quan trọng bạn cần biết:

• IPv6 không bị ảnh hưởng bởi lỗi đầu tiên, vì tcp_v6_syn_recv_sock() sao chép các tùy chọn thay vì chuyển quyền sở hữu.
• Lỗi còn tồn tại từ kernel 4.4 trở đi. Nghĩa là gần như mọi hệ thống Linux đang chạy hiện nay đều nằm trong diện ảnh hưởng, trừ khi distro của bạn đã backport bản sửa.
• Một biến thể tương tự liên quan tới request socket migration (khi bật net.ipv4.tcp_migrate_req=1 hoặc dùng chương trình BPF) cũng được sửa cùng đợt.

3. Vì sao cùng một lỗi mà điểm số lệch nhau tới 4 điểm?

Đây là phần gây tranh cãi nhất, và cũng là phần bạn cần hiểu đúng để khỏi hoang mang. Cùng một CVE-2026-98432 nhưng:

Nguồn chấm điểm	Điểm CVSS	Đánh giá
Nhóm CVE của kernel Linux	9.8	Critical
Oracle Linux, SUSE	8.1	Important
Amazon Linux	7.0	Important
Red Hat (file advisory máy đọc được)	8.1	Important
Red Hat (trang CVE)	5.9	Moderate

Sự khác biệt nằm ở đúng một tiêu chí: độ khó khai thác (attack complexity). Nhóm kernel cho rằng cả hai phía của cuộc đua đều “do kẻ tấn công tạo ra”: kẻ tấn công gửi gói SYN mang tùy chọn IPv4 Record Route hoặc Timestamp, rồi gửi lại gói đó để tranh thủ thắng cuộc đua — nên họ chấm complexity là thấp. Các hãng distro thì cho rằng thắng được cuộc đua này trong thực tế là khó, nên chấm complexity là cao; còn trang CVE của Red Hat thì đi xa hơn, cho rằng kết quả khả dĩ nhất chỉ là crash kernel, và “chưa chứng minh được tác động tới tính bảo mật hay toàn vẹn”.

Ai đúng? Cả hai đều có lý ở tầng giả định của mình: 9.8 mô tả kịch bản xấu nhất khi kẻ tấn công thắng cuộc đua và điều khiển được bộ nhớ kernel; 5.9 mô tả xác suất thắng cuộc đua đó trên hệ thống thật. Anthropic đã làm cán cân nghiêng về phía 9.8 khi chứng minh một mô hình AI có thể thắng cuộc đua một cách có hệ thống, không nhờ may mắn. Dù bạn tin vào con số nào, hãy nhớ: điểm số là tín hiệu ưu tiên, không phải lệnh vá — và với lỗi nằm ngay trên đường nhận kết nối TCP của mọi máy chủ công khai, mình vẫn xếp nó vào nhóm “vá càng sớm càng tốt”.

4. AI viết exploit root trong 53 phút — và những gì chưa được chứng minh

Theo bài đăng ngày 27/10 của Anthropic, exploit của họ chạy theo hai giai đoạn:

1. Rò rỉ địa chỉ kernel (48 phút): lợi dụng cuộc đua để kernel đọc một trường độ dài do kẻ tấn công kiểm soát, sao chép thừa byte rồi gửi trả lại. Chỉ cần một lần trong số các phản hồi đó chứa con trỏ kernel, kẻ tấn công sẽ biết bố cục bộ nhớ kernel và vô hiệu hóa KASLR — cơ chế ngẫu nhiên hóa địa chỉ bộ nhớ của kernel.
2. Chiếm quyền điều khiển (5 phút): dùng cùng lỗi để tràn bộ đệm và ghi đè một con trỏ callback bằng địa chỉ của payload mà kẻ tấn công đã “cài sẵn” trong bộ nhớ kernel qua một tính năng giao thức bình thường. Khi kernel gọi callback đó, payload sẽ xâu chuỗi các hàm kernel có sẵn và kết thúc bằng một lệnh shell chạy dưới quyền root.

Một tính chất khiến cuộc đua này đặc biệt nguy hiểm: thua một lần không làm sập hệ thống — nó chỉ làm hỏng đúng lần bắt tay đó, nên kẻ tấn công có thể thử lại vô hạn lần. 53 phút trong thử nghiệm của Anthropic là thời gian cho một mục tiêu cụ thể trong phòng lab, không phải “thời gian hack mọi máy chủ trên Internet”.

Và đây là những điểm bạn cần giữ tỉnh táo, vì chính The Hacker News cũng nhấn mạnh chúng:

• Bài đăng của Anthropic không kèm code exploit, không nêu phiên bản kernel và cấu hình đã thử nghiệm. Không ai ngoài Anthropic có thể kiểm chứng độc lập exploit này tính đến thời điểm viết bài.
• Hồ sơ CVE và bản sửa đều không nhắc tới MPTCP (Multipath TCP). Mối liên hệ giữa lỗi này với “máy chủ có MPTCP listener” chỉ xuất phát từ bài đăng của Anthropic. Hồ sơ CVE mô tả lỗi TCP IPv4 nói chung, còn bài đăng nói về mục tiêu MPTCP — hai mô tả chưa khớp nhau hoàn toàn.
• Tính đến 29/10, không có báo cáo nào về khai thác thực tế. Lỗi này cũng chưa xuất hiện trong danh mục CISA KEV (các lỗ hổng đã biết bị khai thác). Nói cách khác: đây là lỗi “đã chứng minh khai thác được trong lab”, chưa phải “đang bị khai thác ngoài đời thực”.
• Anthropic cũng nói rõ họ chỉ công bố sau khi các hãng đã có bản vá, theo chính sách công bố phối hợp 90 ngày.

Thông điệp rút ra không phải là “AI sắp hack hết máy chủ”, mà là: chi phí biến một lỗi khó thành exploit hoàn chỉnh đang giảm rất nhanh. Cửa sổ từ “công bố CVE” tới “có exploit thực tế” sẽ ngày càng ngắn lại — vá sớm không còn là lời khuyên thừa nữa.

5. Ai đã vá, ai vẫn đang chờ?

Tình trạng tính đến ngày 29/10/2026, theo tổng hợp của The Hacker News và trang theo dõi CVE của Ubuntu:

Distro / nhánh	Tình trạng	Ghi chú
Debian trixie (stable)	Đã vá 16/10	Gói linux 6.12.113-1 (DSA-6568-1)
Debian 12 (bookworm)	Đã vá 17/10 và 22/10	linux 6.1.190-1; linux-6.12 6.12.113-1~deb12u1
Oracle Linux (UEK)	Đã vá 16/10	ELSA-2026-500397/98/99
SUSE (SLE Micro 6.2, Leap 16.0)	Đã vá	kernel-default 6.12.0-160000.40.1 trở lên
Amazon Linux 2023 (kernel6.18)	Đã vá 24/10	kernel6.18-6.18.56-125.164.amzn2023
Amazon Linux 2023 (kernel6.12)	Đã vá 29/10	kernel6.12-6.12.113-138.209.amzn2023
Ubuntu 22.04 / 24.04 / 26.04 / 26.10	Chưa có bản vá	Trang Ubuntu ghi “Vulnerable, work in progress”, mức ưu tiên High
RHEL 8 / 9 / 10, OpenShift 4	Chưa có bản vá	Red Hat ghi “Fix deferred” — hoãn sang bản cập nhật sau, chưa có ngày cụ thể
SLES 15 SP4–SP6 LTSS, SLES 16.0	Đang thử nghiệm	Chưa phát hành

Nếu bạn tự build kernel, bản sửa đã có trong các nhánh ổn định: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 và 7.3. Nhóm kernel khuyến nghị cập nhật lên kernel ổn định mới nhất thay vì cherry-pick từng bản sửa lẻ.

6. Cách kiểm tra hệ thống của bạn trong 2 phút

Bạn không cần công cụ gì đặc biệt. SSH vào máy chủ và chạy vài lệnh chỉ đọc — chúng không thay đổi gì trên hệ thống:

uname -r
cat /etc/os-release
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
ss -tln

Ý nghĩa từng lệnh: uname -r xem kernel đang chạy (đối chiếu với advisory của distro, không so máy móc với số upstream); cat /etc/os-release xác định distro và phiên bản; hai sysctl kiểm tra cấu hình liên quan tới biến thể migration; ss -tln liệt kê các cổng TCP đang lắng nghe — càng nhiều cổng công khai thì bề mặt tấn công càng lớn.

Mình đã chạy đúng các lệnh này trong môi trường giả lập Ubuntu 24.04 trên máy này, và đây là kết quả thật:

Máy giả lập chạy kernel 7.0.0-39-generic trên Ubuntu 24.04, với net.mptcp.enabled = 1 và net.ipv4.tcp_migrate_req = 0. Lưu ý: mptcp.enabled = 1 chỉ có nghĩa là kernel cho phép MPTCP, không có nghĩa ứng dụng của bạn đang mở listener MPTCP — muốn biết chắc phải kiểm tra ứng dụng, không chỉ sysctl. Và máy giả lập này không có dịch vụ TCP công khai nào đang lắng nghe (lệnh ss chỉ trả về dòng tiêu đề), nên nó chỉ minh họa cách kiểm tra, không phải máy chủ sản phẩm.

Một cảnh báo quan trọng khi đối chiếu phiên bản: đừng so số kernel của distro với số upstream một cách máy móc. Distro thường backport bản sửa vào kernel cũ mà vẫn giữ nguyên số phiên bản chính. Ví dụ, Ubuntu 24.04 có thể vá lỗi này trong gói 6.8.0-149 mà không đổi số 6.8. Cách đúng duy nhất là tra advisory chính thức của distro bạn dùng (trang CVE của Ubuntu, Red Hat, Debian…) và xem gói kernel nào được ghi là “Fixed”.

7. Cách vá và giảm rủi ro, từng bước

Bước 1: Cập nhật ngay nếu distro của bạn đã có bản vá

Trên Debian, Ubuntu (khi bản vá ra mắt), Oracle Linux, SUSE hay Amazon Linux, quy trình chuẩn vẫn là cập nhật gói kernel rồi khởi động lại:

sudo apt update && sudo apt install --only-upgrade linux-image-generic
# hoặc trên RHEL/CentOS: sudo dnf update kernel
# sau đó khởi động lại để kernel mới có hiệu lực
sudo reboot

Kernel mới chỉ có hiệu lực sau khi reboot — cập nhật mà không reboot thì máy vẫn chạy kernel cũ. Hãy đặt lịch reboot vào khung giờ thấp điểm và kiểm tra lại bằng uname -r sau đó. Với cụm Kubernetes, kernel là tài nguyên dùng chung của cả node: mọi pod đều thừa hưởng bề mặt tấn công của kernel host, nên vá node phải ưu tiên ngang với vá ứng dụng.

Bước 2: Nếu distro của bạn chưa có bản vá (Ubuntu, RHEL)

Tính đến 29/10, Red Hat nói thẳng là không có biện pháp giảm thiểu nào đáp ứng tiêu chuẩn “dễ triển khai, phù hợp đa số cài đặt và ổn định” của họ, và các advisory khác cũng không liệt kê mitigation chính thức nào. Vì vậy đừng tin mẹo “tắt MPTCP là xong” — chưa có advisory hay bài đăng nào khẳng định điều đó, vì bản thân mối liên hệ MPTCP — CVE còn chưa được hồ sơ CVE xác nhận.

Những việc bạn vẫn làm được ngay, và nên làm:

1. Thu hẹp bề mặt TCP công khai: chỉ mở những cổng thật sự cần thiết, dùng firewall (UFW, firewalld, security group của cloud) chặn phần còn lại. Kẻ tấn công phải chạm được vào dịch vụ TCP của bạn thì mới chạm được vào lỗi này.
2. Theo dõi advisory của distro mỗi ngày cho tới khi bản vá xuất hiện: trang CVE của Ubuntu, Red Hat, hoặc bật thông báo từ kênh bảo mật của distro.
3. Chuẩn bị sẵn khung giờ bảo trì: khi bản vá ra, bạn chỉ việc chạy cập nhật + reboot, thay vì cuống cuồng xin downtime lúc đó.
4. Ưu tiên máy chủ lộ mặt Internet trước, rồi mới tới máy nội bộ. Máy chỉ nghe trên localhost hoặc sau VPN có mức độ khẩn thấp hơn hẳn.

Bước 3: Sau khi vá

Chạy lại bộ lệnh ở mục 6, đối chiếu kernel mới với advisory và kiểm tra dịch vụ đã lên lại bình thường chưa. Nếu bạn dùng livepatch (Canonical Livepatch, KernelCare…), hãy kiểm tra xem nhà cung cấp đã đẩy bản vá cho CVE này chưa — không phải lỗi kernel nào cũng được hỗ trợ livepatch.

8. Kết luận

CVE-2026-98432 là một trường hợp đáng học hỏi: lỗi tồn tại từ kernel 4.4, sửa bằng vài dòng code, nhưng phơi bày đủ thứ — cách các hãng chấm điểm khác nhau, tốc độ đóng gói bản vá chênh lệch giữa các distro, và thực tế là AI giờ đã viết được exploit cho lỗi đua tranh phức tạp trong chưa đầy một giờ. Điểm 9.8 hay 5.9 không quan trọng bằng một câu hỏi đơn giản: kernel trên máy chủ của bạn đã được vá chưa, và bạn có lịch reboot cho nó chưa?

Nếu máy bạn chạy Debian, Oracle Linux, SUSE hay Amazon Linux: cập nhật ngay hôm nay. Nếu bạn chạy Ubuntu hay RHEL: đặt nhắc theo dõi advisory, thu hẹp cổng công khai, và chuẩn bị sẵn khung giờ bảo trì. Và nếu bạn quản trị nhiều máy chủ, hãy coi đây là dịp để rà lại toàn bộ danh sách kernel trong hạ tầng của mình — vì “Black October” vừa qua đã cho thấy, lỗi kernel không còn là chuyện của riêng nhóm hệ thống nữa.

FAQ

CVE-2026-98432 có đang bị khai thác ngoài đời thực không?

Tính đến 29/10/2026, không. Không có advisory, hồ sơ CVE hay bài đăng nào của Anthropic báo cáo khai thác thực tế, và lỗi này chưa có trong danh mục CISA KEV. Đây là exploit phòng lab đã được chứng minh, chưa phải chiến dịch tấn công đang diễn ra.

Máy tính cá nhân dùng Linux có cần lo không?

Rủi ro thấp hơn nhiều so với máy chủ. Khai thác này nhắm tới máy chủ có dịch vụ TCP lộ ra mạng; máy cá nhân sau NAT, không mở cổng công khai, ít có khả năng trở thành mục tiêu — nhưng bạn vẫn nên cập nhật kernel theo lịch của distro.

Tắt MPTCP có vá được lỗi này không?

Chưa có bằng chứng chính thức nào khẳng định điều đó. Hồ sơ CVE mô tả lỗi TCP IPv4 nói chung và không nhắc tới MPTCP; các advisory cũng không liệt kê việc tắt MPTCP như biện pháp giảm thiểu. Đừng coi đó là bản vá thay thế.

Vì sao Ubuntu và RHEL chậm hơn Debian hay Oracle?

Mỗi distro có quy trình kiểm thử và backport riêng, nhất là với bản LTS và kernel doanh nghiệp cần đảm bảo ổn định. “Chậm” không có nghĩa là bỏ mặc — Ubuntu ghi “work in progress”, Red Hat ghi “fix deferred”. Bạn cần theo dõi advisory thay vì đoán ngày phát hành.

Cập nhật kernel có bắt buộc reboot không?

Có, trừ khi bạn dùng giải pháp livepatch và nhà cung cấp đã hỗ trợ CVE này. Kernel đang chạy chỉ được thay bằng kernel mới sau khi khởi động lại, nên hãy lên lịch reboot và kiểm tra lại bằng uname -r sau đó.

Nguồn tham khảo

• Hồ sơ CVE chính thức CVE-2026-98432 — CVE.org
• Trang theo dõi CVE-2026-98432 của Ubuntu (mức ưu tiên, trạng thái từng bản phát hành)
• Anthropic: Discovering and exploiting vulnerabilities in critical, real-world software with Claude (27/10/2026)
• The Hacker News: Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions (29/10/2026)
• Dark Reading: Claude Model Exploits Major Browsers, OSes