Ba lỗi Linux đã bị khai thác: vá xong vẫn cần kiểm tra kernel đang chạy
Ngày 18/9/2026, Cơ quan An ninh mạng và An ninh Cơ sở hạ tầng Mỹ (CISA) bổ sung ba lỗ hổng Linux kernel vào danh mục Known Exploited Vulnerabilities (KEV) vì có bằng chứng chúng đang bị khai thác. Ba mã là CVE-2025-39682 trong đường nhận TLS, CVE-2026-53266 ở ebtables SNAT và CVE-2025-39964 trong AF_ALG; tổng hợp của The Hacker News cho biết chưa có thông tin công khai về cách khai thác hoặc việc ba lỗi có nằm trong cùng một chuỗi tấn công hay không.
Từ sự kiện ngày 18/9/2026, ba lỗi này cần được ưu tiên theo trạng thái khai thác thực tế, không chỉ theo điểm CVSS. Với quản trị viên, cài gói mới chưa đủ: máy chủ chỉ nhận bản sửa khi kernel đã vá thực sự được nạp, bằng cách khởi động lại hoặc qua cơ chế live patch được nhà cung cấp xác nhận; sau đó vẫn phải xem xét khả năng hệ thống đã bị xâm nhập trước lúc vá.
Ba CVE tác động đến ba đường xử lý khác nhau
- CVE-2025-39682 — đường nhận kernel TLS: lỗi kiểm tra trạng thái bất thường có thể cho phép người dùng cục bộ đã xác thực gây lộ bộ nhớ hoặc từ chối dịch vụ. Bản sửa upstream đã được công bố từ năm 2025; điểm mới là bằng chứng khai thác khiến lỗi được đưa vào KEV.
- CVE-2026-53266 — ebtables SNAT: lỗi ghi ngoài biên xuất hiện trong đường viết lại địa chỉ phần cứng của bên gửi ARP. Việc khai thác đòi hỏi quyền truy cập cục bộ và cấu hình bridge netfilter với quy tắc ebtables SNAT phù hợp; hậu quả có thể là hành vi ngoài dự kiến, từ chối dịch vụ hoặc leo thang đặc quyền.
- CVE-2025-39964 — AF_ALG: điều kiện tranh chấp khi có các lần ghi đồng thời vào cùng socket AF_ALG có thể làm sập hệ thống hoặc làm hỏng kết quả của phép toán mật mã, ảnh hưởng đến tính sẵn sàng hay toàn vẹn dữ liệu.
phân tích ngày 18/9 của IntelFusions đối chiếu cả ba mục và lưu ý CVE-2025-39682 đã có bản sửa khoảng một năm trước. Vì vậy, tuổi của bản vá không cho biết một máy cụ thể đã an toàn: máy vẫn có thể chạy nhánh chưa nhận bản sửa hoặc chưa khởi động vào kernel mới.
Phiên bản nhìn có vẻ cũ chưa chắc còn lỗ hổng
Các bản phân phối hỗ trợ dài hạn thường backport bản sửa vào nhánh kernel hiện có. Chuỗi phiên bản vì thế có thể thấp hơn phiên bản upstream đã sửa nhưng gói của nhà phân phối vẫn không còn lỗi; chiều ngược lại, một số phiên bản cao hơn cũng không tự chứng minh rằng đúng bản vá đã được tích hợp.
Việc đối chiếu phải dựa trên advisory, errata hoặc dữ liệu bảo mật của đúng nhà phân phối, đúng bản phát hành, kiến trúc và kernel flavour. Kernel mặc định, cloud, real-time, low-latency và các biến thể do nhà cung cấp thiết bị đóng gói có thể nhận bản sửa ở những gói khác nhau.
Riêng với CVE-2026-53266, hồ sơ CVE chính thức của Red Hat xác định điều kiện là các quy tắc bridge netfilter chuyên biệt và nêu biện pháp giảm thiểu: vô hiệu hóa việc viết lại địa chỉ phần cứng ARP hoặc loại bỏ quy tắc ebtables SNAT áp dụng cho lưu lượng ARP trên bridge. Red Hat chấm 7,5 trong khi cve.org chấm 8,8 vì cách đánh giá còn phụ thuộc phiên bản, cách build và phạm vi sản phẩm; con số chung không thay thế kết luận affected hay fixed của nhà cung cấp.
Đối chiếu kernel đang chạy với gói đã cài
Lệnh chỉ đọc uname -r cho biết kernel đang hoạt động; uname -a bổ sung kiến trúc và thông tin build. Trên Debian hoặc Ubuntu, có thể liệt kê gói bằng dpkg-query -W 'linux-image*'; trên hệ RPM, dùng rpm -q kernel kernel-core. Tên gói thực tế có thể khác giữa các bản phân phối.
Nếu trình quản lý gói hiển thị kernel đã sửa nhưng uname -r vẫn trả về bản cũ, bản cập nhật chưa bảo vệ kernel đang chạy. Ngoại lệ là khi nhà cung cấp xác nhận live patch tương ứng đã được nạp thành công; sự hiện diện của dịch vụ live patch tự nó không chứng minh bản sửa cho cả ba CVE đã hoạt động.
- Ghi lại uname -r và thời điểm khởi động bằng uptime -s.
- Liệt kê các gói kernel đã cài và xác định gói chứa kernel đang chạy. Có thể thử dpkg-query -S /boot/vmlinuz-$(uname -r) trên Debian hoặc Ubuntu, hay rpm -qf /boot/vmlinuz-$(uname -r) trên hệ RPM; bố cục thư mục khởi động có thể khác.
- Đối chiếu gói đó với thông báo chính thức cho từng CVE, đúng bản phát hành và kernel flavour.
- Nếu cần khởi động lại, thực hiện trong cửa sổ bảo trì rồi kiểm tra lại uname -r sau khi máy trở về trạng thái phục vụ.
Trong container, uname -r thường phản ánh kernel của host. Cập nhật image hoặc gói user space trong container không thay thế việc vá node cung cấp kernel cho workload; đội vận hành phải xác định đúng host hoặc node cần xử lý.
Vá xong vẫn phải rà soát thời gian phơi nhiễm
KEV xác nhận có khai thác trong thực tế nhưng chưa cung cấp chỉ báo xâm nhập chuyên biệt cho ba lỗi. Do đó, sự vắng mặt của một IOC công khai không phải bằng chứng rằng máy sạch, nhất là khi hệ thống đã chạy kernel dễ bị ảnh hưởng trước khi cập nhật.
Phạm vi rà soát nên bám vào khoảng thời gian phơi nhiễm và telemetry sẵn có: sự cố kernel hoặc lần khởi động lại bất thường, lỗi bộ nhớ và network stack trong journalctl -k, thay đổi đặc quyền không giải thích được, tài khoản hay khóa SSH mới, module ngoài chuẩn, cơ chế duy trì trái phép và sai lệch của tệp hệ thống quan trọng. Đây là hoạt động điều tra sau phơi nhiễm, không phải cách xác định gói nào đã được vá.
Điều kiện sử dụng subsystem giúp sắp xếp ưu tiên nhưng không thay thế advisory của nhà phân phối. Đội vận hành có thể kiểm kê kernel TLS, AF_ALG, bridge interface và quy tắc ebtables SNAT xử lý ARP; nếu không dùng một đường xử lý, bề mặt tấn công tương ứng có thể giảm, nhưng kết luận cuối cùng vẫn phải gắn với cấu hình và gói cụ thể.
Trạng thái có thể đóng cảnh báo gồm ba bằng chứng riêng biệt: nhà phân phối xác nhận gói chứa bản sửa hoặc backport, kernel đó thực sự đang chạy, và việc rà soát không phát hiện dấu hiệu cần điều tra tiếp. Phạm vi nạn nhân và kỹ thuật khai thác của ba lỗi vẫn chưa được công bố, nên cập nhật từ CISA và các nhà phân phối vẫn là dữ liệu cần theo dõi sau cửa sổ bảo trì.
Đọc thêm:
Đăng ký bản tin
Nhận tin Web3, AI và tiền mã hóa mới nhất ngay trong hộp thư.