CVE-2026-98432: Lỗ hổng use-after-free TCP trong nhân Linux và bài học về xác minh bản vá

Lỗ hổng CVE-2026-98432 là một lỗi use-after-free (sử dụng bộ nhớ sau khi giải phóng) trong đường xử lý handshake TCP IPv4 của nhân Linux. Lỗi xuất hiện khi hai CPU xử lý đồng thời một request socket và child socket có liên quan, nhưng cả hai vẫn tham chiếu đến cùng một đối tượng IP options. Điểm CVSS 3.1 được ghi nhận là 9.8, nhưng cách đánh giá và bản chất khai thác thực tế lại phức tạp hơn nhiều so với con số này.

Bản chất kỹ thuật: khi vòng đời bộ nhớ không khớp với cơ chế đồng bộ

Vấn đề nằm ở việc chuyển giao quyền sở hữu dữ liệu IPv4 options giữa request socket và child socket. Trong quá trình handshake TCP phía máy chủ, nhân Linux tạo một request socket nhẹ để đại diện cho kết nối chưa hoàn tất. Khi handshake tiến triển, hàm tcp_v4_syn_recv_sock() chuyển con trỏ ireq_opt của request sang child socket thành inet_opt — nhưng không sao chép đối tượng, chỉ chuyển con trỏ.

Song song đó, một CPU khác có thể xử lý gói SYN truyền lại của cùng request đó và gửi thêm SYN-ACK thông qua tcp_check_req(). Các hàm như tcp_v4_send_synack() và inet_csk_route_req() đọc IP options bên trong vùng tới hạn đọc RCU (RCU read-side critical section). Về lý thuyết, RCU đảm bảo dữ liệu vẫn hợp lệ cho đến khi vùng đọc kết thúc.

Vấn đề cốt lõi: bên đọc hành xử như thể RCU bảo vệ đối tượng, nhưng hàm hủy lại giải phóng nó bằng kfree() thông thường — không chờ các reader RCU hiện có hoàn tất.

Nếu child socket bị hủy trong khi đường xử lý SYN truyền lại vẫn đang dùng options, CPU thứ hai có thể tiếp tục đọc vùng nhớ không còn thuộc về đối tượng đó. Bản vá chính thức thay thế việc giải phóng tức thì bằng kfree_rcu() trong các destructor liên quan, trì hoãn việc thu hồi cho đến khi hết một chu kỳ grace period của RCU.

Ngoài ra còn có biến thể liên quan đến di chuyển request (request migration). Khi net.ipv4.tcp_migrate_req=1 được bật, hoặc khi một chương trình BPF SK_REUSEPORT_SELECT_OR_MIGRATE điều khiển việc di chuyển request, nhân có thể nhân bản request socket. Request cũ và bản sao tạm thời chia sẻ cùng một đối tượng options, mở ra cửa sổ mà một CPU giữ tham chiếu đến request cũ vẫn dùng đối tượng trong khi bản sao bị giải phóng.

Minh họa lỗi use-after-free trong đường xử lý TCP handshake

Cần phân biệt rõ: lỗi chính thuộc đường child-socket của IPv4, vì hàm tương ứng của IPv6 sao chép options thay vì chuyển con trỏ. Tuy nhiên, khẳng định "IPv6 không bị ảnh hưởng" là quá rộng — mô tả upstream cũng ghi nhận một quan ngại riêng về di chuyển request IPv6 liên quan đến ipv6_opt khi có CALIPSO, và điều kiện này được xử lý tách biệt.

Vì sao điểm CVSS lại khác nhau giữa các bên

Bản ghi CVE mang vector CVSS 3.1 là AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, tương ứng 9.8 — kịch bản xấu nhất: tấn công qua mạng, không cần tài khoản, không cần tương tác người dùng, ảnh hưởng cao đến cả ba yếu tố bảo mật. Trong khi đó:

• Red Hat chấm 5.9, coi đây là một race condition khó khai thác và đánh giá hậu quả thực tế trên sản phẩm của họ thận trọng hơn.
• Ubuntu hiển thị 9.8 nhưng công bố thêm đánh giá CVSS 4.0 là 8.3 với các điều kiện tấn công cụ thể, đồng thời theo dõi trạng thái vá cho từng gói nhân riêng biệt.
• Nhóm Frontier Red Team của Anthropic báo cáo đã xây dựng được chuỗi khai thác root từ xa trên máy chủ Linux có listener Multipath TCP trong môi trường thí nghiệm có kiểm soát.

Ba đánh giá này bổ sung cho nhau, không loại trừ nhau. Bản ghi upstream xác định lỗi vòng đời bộ nhớ nguy hiểm và tác động lý thuyết tối đa. Điểm số của nhà phân phối phản ánh mã nguồn, cấu hình, biện pháp giảm thiểu và điều kiện khai thác thực tế trên sản phẩm họ phát hành. Còn nghiên cứu của Anthropic chứng minh một đường khai thác cụ thể qua một mục tiêu cụ thể.

Kết quả của Anthropic là bằng chứng nghiêm túc về khả năng khai thác trong một cấu hình cụ thể. Đây không phải bằng chứng rằng mọi máy chủ Linux chưa vá, mọi listener TCP thông thường hay mọi bản phân phối đều có thể bị xâm phạm theo cùng một cách.

Hướng ứng phó thực tế cho đội ngũ vận hành

Phản ứng thực tế khá trực tiếp, nhưng đòi hỏi kỷ luật trong khâu xác minh:

1. Xác định các dịch vụ TCP Linux có thể bị chạm tới từ mạng không tin cậy: reverse proxy, web server, API gateway, ingress node, VPN concentrator, load balancer, bastion SSH, endpoint cơ sở dữ liệu và các daemon tự phát triển.
2. Xác định chính xác nhân nào đang chạy — nhân của bản phân phối, image cloud, firmware thiết bị hay bản build tùy chỉnh.
3. Cài bản build đã vá do nhà cung cấp phát hành, sau đó khởi động lại vào nhân mới.
4. Lưu bằng chứng rằng nhân đang chạy thực sự chứa bản sửa lỗi.

Các máy chủ mở listener MPTCP cần được ưu tiên ngay lập tức, vì nghiên cứu công khai đã xác nhận chính môi trường này. Gateway hướng internet, load balancer, node Kubernetes, VPN endpoint, reverse proxy và các thiết bị appliance dùng mạng Linux cũng nên được kiểm kê nhanh, kể cả khi không chủ động bật MPTCP.

Quy trình kiểm kê và xác minh bản vá kernel

Cạm bẫy khi kiểm tra phiên bản

Không có một chuỗi phiên bản upstream duy nhất nào mô tả chính xác mọi nhân của nhà cung cấp. Các bản phân phối doanh nghiệp thường backport bản vá bảo mật trong khi vẫn giữ phiên bản gốc trông có vẻ cũ. Các nhà cung cấp cloud và hãng thiết bị có thể phát hành nhân riêng.

Công cụ quét chỉ so sánh uname -r với danh sách phiên bản upstream có thể tạo ra cả cảnh báo sai lẫn bỏ sót. Kết luận có cơ sở chỉ đến từ: thông báo của nhà cung cấp, changelog gói, metadata build, tuyên bố VEX hoặc xác nhận trực tiếp rằng commit sửa lỗi đã được backport.

Bảng trạng thái tham khảo

Nguồn	Trạng thái ghi nhận
Debian	Bookworm với gói 6.1.190-1, Trixie với gói 6.12.113-1
Ubuntu	Theo dõi riêng từng gói nhân: generic, AWS, Azure, GCP, KVM, Oracle, OEM, low-latency, real-time
Upstream stable	5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 và nhánh 7.3
Red Hat	Cần tra trang CVE và errata cho đúng sản phẩm RHEL/OpenShift

Bản vá được merge upstream với commit e3f33b0a1d89, tiêu đề "ipv4: free inet_opt and ireq_opt after an RCU grace period". Lỗi được đưa vào qua các thay đổi cũ hơn, trong đó có commit 079096f103fa.

Containers và Kubernetes: cái bẫy phổ biến nhất

Container thường chia sẻ nhân với máy chủ. Cập nhật image ứng dụng không thay thế nhân xử lý lưu lượng TCP của nó. Với khách hàng Kubernetes được quản lý, có thể cần cập nhật node image, rollout node pool hoặc chờ nhà cung cấp bảo trì. Với cluster tự quản lý, cần cập nhật gói trên máy chủ và khởi động lại từng node.

Đừng khởi động lại container, deploy lại ứng dụng hay cập nhật thư viện user-space rồi coi như đã xử lý xong. Mã lỗ hổng chạy trong nhân máy chủ.

Với hệ thống dùng live patching, chỉ chấp nhận trạng thái này khi nhà cung cấp xác nhận rõ ràng rằng bản live patch đó bao phủ CVE-2026-98432. Bản sửa lỗi tác động đến cơ chế thu hồi đối tượng trong destructor mạng, nên mức độ bao phủ phụ thuộc vào cách triển khai của từng hãng.

Sau khi rollout, cần kiểm tra cả launch template, node image, golden image, recovery media và định nghĩa disaster recovery. Một image cũ có thể tái tạo node dễ bị tổn thương sau đợt rollout đầu tiên. Hãy thử một sự kiện scale-out và xác nhận node mới khởi động với nhân đã vá.

Biến thể di chuyển request và các biện pháp giảm thiểu tạm thời

Với biến thể request migration, quản trị viên có thể kiểm tra thông qua:

• ip mptcp endpoint show và ip mptcp limits show để xem cấu hình MPTCP
• sysctl net.mptcp.enabled để kiểm tra trạng thái bật/tắt
• sysctl net.ipv4.tcp_migrate_req để xem cấu hình di chuyển request
• Danh sách chương trình BPF reuseport gắn với nhóm listener

Trong trường hợp chưa thể mở cửa sổ bảo trì ngay, có thể giảm phơi nhiễm bằng cách tắt MPTCP nếu không dùng, giới hạn TCP inbound theo nguồn và cổng cần thiết, đưa dịch vụ quản trị ra sau gateway có xác thực, loại bỏ listener công khai không dùng. Tuy nhiên, cần hiểu rõ giới hạn:

Tắt MPTCP không loại bỏ lỗi vòng đời IPv4 gốc. Nó chỉ loại bỏ đúng cấu hình listener đã được dùng trong chuỗi nghiên cứu công khai. Triển khai bản vá vẫn là biện pháp khắc phục bền vững.

Chặn toàn bộ IPv4 options ở biên mạng có thể giảm phơi nhiễm nhưng là biện pháp không đầy đủ và có thể gây gián đoạn, bởi một số mạng dùng options cho hành vi chuyên biệt. Chỉ nên coi đây là giảm thiểu rủi ro tạm thời.

Các biện pháp như WAF hay firewall lớp ứng dụng không thấy được trạng thái handshake IP/TCP liên quan, vì chúng bắt đầu xử lý sau khi kết nối TCP đã được thiết lập — tức là sau thao tác dễ bị tổn thương.

Phát hiện tấn công: kết hợp nhiều nguồn tín hiệu

Khai thác lỗi hỏng bộ nhớ hiếm khi tạo ra một dòng log duy nhất đủ rõ ràng. Cần kết hợp:

• Telemetry nhân: crash với stack gần ip_options_build(), ip_build_and_send_pkt(), quá trình tạo SYN-ACK hoặc destructor socket. Báo cáo KASAN xác định use-after-free liên quan inet_opt/ireq_opt đặc biệt đáng chú ý trong môi trường test.
• Hành vi mạng: client gửi lặp lại nhiều lần kết nối với tổ hợp option bất thường hoặc duy trì retry nhắm vào listener MPTCP. Nhưng phải lấy baseline trước, vì mạng di động, đường truyền mất gói và health check cũng tạo ra lượng retransmission cao.
• Trạng thái máy chủ: tiến trình root bất thường, thay đổi cấu hình khởi động, kết nối mạng mới, hoạt động module, sự kiện audit và cảnh báo giám sát toàn vẹn.

Theo mô tả của Anthropic, chuỗi khai thác cần nhiều cơ hội lặp lại trong khoảng thời gian dài — khoảng 48 phút để lộ con trỏ nhân và thêm khoảng 5 phút để đạt thực thi lệnh. Một lần thất bại có thể để lại handshake chưa hoàn tất mà không nhất thiết làm sập máy chủ, cho phép thử lại nhiều lần.

Nếu nghi ngờ bị khai thác, cần cô lập máy chủ bằng biện pháp mạng có bảo toàn bằng chứng, thu thập trạng thái biến động, luân chuyển thông tin xác thực mà máy chủ có thể truy cập, và điều tra các hệ thống lân cận. Một khi nhân đã bị xâm phạm, mọi giả định về tính toàn vẹn của log user-space và agent bảo mật đều không còn giá trị — cần dựng lại từ image tin cậy, không coi việc cập nhật gói là khắc phục cho máy đã bị chiếm quyền.

Kiểm tra log nhân và telemetry mạng trong quy trình xác minh sau vá

Bảy sai lầm thường gặp khi xử lý lỗ hổng này

1. Coi "Linux" là một sản phẩm duy nhất. Nhân được phát hành qua bản phân phối, image cloud, firmware nhúng, node image được quản lý và bản build tùy chỉnh — mỗi kênh có thể có backport khác nhau.
2. Đánh đồng điểm CVSS với mức độ khai thác thực tế. Điểm 9.8 mô tả mức nghiêm trọng kỹ thuật, không đếm số máy chủ bị ảnh hưởng hay chứng minh đang bị khai thác.
3. Đọc kết quả Anthropic như phổ quát. Nghiên cứu chứng minh một nhóm có năng lực khai thác được listener MPTCP trong phòng thí nghiệm của họ, không chứng minh hành vi giống hệt với mọi listener TCP.
4. Tuyên bố IPv6 an toàn tuyệt đối. Lỗi chuyển giao child-socket là đặc thù IPv4, nhưng vẫn có quan ngại riêng về di chuyển request IPv6 với CALIPSO.
5. Chỉ quét container ứng dụng. Image container không mang nhân máy chủ đang hoạt động trong mô hình thông thường.
6. Thử mã khai thác công khai trên production. Thắng cuộc đua có thể làm sập hoặc xâm phạm máy, và gần như không mang lại giá trị nghiệp vụ bổ sung.
7. Đóng ticket sau khi cài đặt mà không khởi động lại. Nhân cũ vẫn hoạt động cho đến khi hệ thống boot vào image mới.

Bài học kỹ thuật rộng hơn

Bài học quan trọng nhất vượt ra ngoài phạm vi CVE này: bảo vệ RCU là một hợp đồng giữa bên đọc và bên thu hồi. Một khóa đọc không thể bảo vệ đối tượng mà bên ghi trả thẳng về allocator. Bản vá khôi phục hợp đồng đó bằng cách chờ reader trước khi giải phóng IP options dùng chung.

Quy trình xác minh cũng cần khôi phục một hợp đồng vận hành: tổ chức phải biết máy chủ nào đã bị phơi nhiễm, chúng đang chạy mã đã vá nào, và dịch vụ còn hoạt động bình thường sau khi khắc phục hay không.

Với độc giả Việt Nam đang vận hành hạ tầng Linux — từ VPS, hệ thống Kubernetes trên cloud đến các appliance tại chỗ — đây là lời nhắc về tầm quan trọng của việc lập bản đồ tài sản mạng, theo dõi nguồn tin bảo mật chính thức từ nhà cung cấp và duy trì quy trình vá lỗi có xác minh thay vì chỉ dựa vào con số phiên bản hay điểm số CVSS.