Hai lỗ hổng có khả năng dẫn đến thực thi mã từ xa trong KSMBD vừa được công bố trên mailing list của cộng đồng Linux, trước khi bản vá được tích hợp vào kernel mainline. Cùng được ZDI đánh giá CVSS 9.0, các điểm yếu này đặt ra yêu cầu cấp thiết: xác định hệ thống thực sự bị ảnh hưởng, thu hẹp bề mặt tấn công và tăng cường giám sát trong thời gian chờ cập nhật.
KSMBD là thành phần máy chủ SMB hoạt động trong Linux kernel, phục vụ nhu cầu chia sẻ tệp qua mạng. Khác với dịch vụ chạy ở không gian người dùng, việc xử lý yêu cầu trực tiếp trong kernel khiến các lỗi an toàn bộ nhớ tại đây có thể tác động nghiêm trọng đến toàn bộ máy chủ.
Hai lỗ hổng được theo dõi bằng mã ZDI-CAN-33774 và ZDI-CAN-33549. Tuy nhiên, phạm vi phơi nhiễm và điều kiện khai thác của từng lỗi khác nhau. Doanh nghiệp cần đánh giá dựa trên kernel, cấu hình dịch vụ và khả năng tiếp cận qua mạng, thay vì mặc định mọi máy chủ Linux đều bị ảnh hưởng.
ZDI-CAN-33774: Lỗi tranh chấp trong cơ chế xử lý giao thức SMB
Theo báo cáo kỹ thuật được công bố, ZDI-CAN-33774 liên quan đến race condition – lỗi điều kiện tranh chấp trong quá trình lựa chọn bộ xử lý giao thức của KSMBD.
Vấn đề xuất hiện khi trạng thái giao thức của kết nối thay đổi trong lúc các yêu cầu trước đó vẫn đang chờ xử lý. Sự thiếu đồng bộ có thể khiến dữ liệu SMB1 được chuyển đến bộ xử lý SMB2, dù cấu trúc và kích thước bộ đệm của hai loại yêu cầu khác nhau.
Hệ quả là KSMBD có thể đọc vượt giới hạn bộ đệm, làm phát sinh nguy cơ lộ dữ liệu trong bộ nhớ kernel. Báo cáo cũng mô tả một nhánh xử lý có khả năng dẫn đến ghi vượt giới hạn bộ đệm khi đáp ứng thêm điều kiện truy cập tài nguyên chia sẻ.
Một số thao tác kích hoạt có thể diễn ra trước bước xác thực. Tuy vậy, cần phân biệt giữa khả năng kích hoạt lỗi, làm lộ bộ nhớ và hoàn thiện chuỗi khai thác thực thi mã từ xa. Không nên diễn giải rằng chỉ cần mở cổng 445 là kẻ tấn công chắc chắn có thể chiếm quyền máy chủ.
ZDI-CAN-33549: Lỗi tính toán kích thước trong SMB Direct
Lỗ hổng thứ hai nằm trong luồng xử lý SMB Direct, cơ chế sử dụng RDMA để truyền dữ liệu với độ trễ thấp và giảm tải xử lý cho CPU.
Theo báo cáo, lỗi tràn dưới số nguyên (integer underflow) xảy ra khi máy chủ xử lý thông tin mô tả bộ đệm RDMA không nhất quán với kích thước dữ liệu đã khai báo. Phép tính kích thước có thể bị quay vòng, khiến thao tác sao chép tiếp theo ghi dữ liệu ra ngoài vùng nhớ được cấp phát.
Khả năng tiếp cận lỗi phụ thuộc vào các điều kiện của môi trường, bao gồm:
- KSMBD sử dụng SMB Direct.
- Hệ thống có giao diện hỗ trợ RDMA, thông qua phần cứng hoặc giải pháp phần mềm như RXE.
- Có tài nguyên chia sẻ cho phép ghi và kết nối đáp ứng các điều kiện xử lý liên quan.
Do đó, việc máy chủ không sử dụng card mạng RDMA chuyên dụng chưa đủ để loại trừ rủi ro. Quản trị viên cần kiểm tra cả cấu hình RDMA bằng phần mềm và các đường kết nối đang hoạt động.
Vì sao lỗi trong KSMBD cần được ưu tiên xử lý?
Dịch vụ chia sẻ tệp thường kết nối nhiều nhóm người dùng, máy trạm và hệ thống nghiệp vụ. Khi thành phần xử lý yêu cầu mạng nằm trong kernel, một lỗi an toàn bộ nhớ có thể vượt khỏi phạm vi của một phiên truy cập tệp.
Tùy khả năng khai thác và kiến trúc triển khai, các kịch bản rủi ro cần đánh giá gồm:
- Lộ dữ liệu trong bộ nhớ, có thể hỗ trợ những bước tấn công tiếp theo.
- Gián đoạn dịch vụ, nếu lỗi khiến kernel gặp sự cố hoặc máy chủ ngừng hoạt động.
- Thực thi mã trái phép, khi kẻ tấn công đáp ứng được các điều kiện khai thác.
- Mở rộng phạm vi xâm nhập, nếu máy chủ bị kiểm soát có quyền truy cập tới dữ liệu và hệ thống khác.
Đây là những tác động tiềm tàng cần được xem xét theo từng môi trường, không phải bằng chứng cho thấy các hệ thống KSMBD đã bị khai thác trên diện rộng.
Rủi ro cũng không chỉ đến từ Internet. Một máy trạm bị xâm nhập hoặc tài khoản VPN bị chiếm quyền có thể tạo đường tiếp cận đến dịch vụ SMB trong mạng nội bộ.
Công bố kỹ thuật và bản vá
Các báo cáo ban đầu ngày 22/10/2026 cho biết chi tiết lỗ hổng đã xuất hiện công khai trước khi bản sửa được tích hợp vào kernel mainline. Trong quá trình xử lý, mã sửa lỗi có thể xuất hiện trước ở nhánh của maintainer, sau đó mới được đưa vào các nhánh phát hành và gói kernel của từng bản phân phối.
Vì vậy, có bản sửa trong nhánh phát triển không đồng nghĩa máy chủ doanh nghiệp đã có bản cập nhật sẵn sàng triển khai. Ngược lại, việc chưa thấy một phiên bản kernel mới cũng không đủ để kết luận nhà cung cấp chưa khắc phục, bởi bản vá có thể được backport vào gói kernel hiện hành.
Doanh nghiệp cần đối chiếu thông báo của bản phân phối đang sử dụng, phiên bản gói cài đặt và trạng thái khắc phục cụ thể. Không nên chờ mã CVE mới bắt đầu kiểm kê và giảm thiểu phơi nhiễm.
Việc xử lý báo cáo có hỗ trợ AI cũng cần được nhìn nhận chính xác. Tài liệu Linux kernel yêu cầu coi các phát hiện có AI hỗ trợ là thông tin công khai, nhưng đồng thời lưu ý không công bố công cụ tái hiện lỗi và yêu cầu người báo cáo xác minh vấn đề, làm rõ điều kiện kích hoạt, cũng như đề xuất bản sửa đã kiểm tra. Chính sách này không đồng nghĩa mọi chi tiết khai thác đều nên được công bố ngay lập tức.
Cùng đợt báo cáo còn có các lỗ hổng khác tại những thành phần khác của Linux kernel:
- ZDI-CAN-33367: liên quan đến
skb_zerocopytrong ngăn xếp mạng, được báo cáo có khả năng dẫn đến leo thang đặc quyền cục bộ. - ZDI-CAN-34068: lỗi ghi ngoài giới hạn trong driver đồ họa VMware
vmwgfx, liên quan đến nguy cơ leo thang đặc quyền cục bộ. - ZDI-CAN-34076: vấn đề trong thành phần NVMe target
nvmet, liên quan đến nguy cơ lộ thông tin.
Một báo cáo khác, ZDI-CAN-32005, liên quan đến ConnMan — dịch vụ quản lý kết nối mạng hoạt động ngoài Linux kernel.
Các lỗi này cần được đánh giá riêng theo thành phần đang sử dụng. Không nên gộp chúng thành cùng một nhóm rủi ro SMB hoặc áp dụng chung một biện pháp khắc phục.
Doanh nghiệp cần làm gì trong thời gian chờ cập nhật?
1. Kiểm kê chính xác việc sử dụng KSMBD
Xác định máy chủ nào có KSMBD, module nào đang được nạp, dịch vụ nào đang phục vụ kết nối và tài nguyên chia sẻ nào đang được công bố. Cần phân biệt KSMBD với Samba chạy trong không gian người dùng; việc mở cổng 445 không tự xác định được phần mềm đứng phía sau.
Kiểm tra module và trạng thái dịch vụ chỉ là bước đầu. Một lần kiểm tra không thấy module trong danh sách chưa đủ để kết luận hệ thống không có thành phần này, đặc biệt khi kernel được biên dịch tùy chỉnh.
2. Vô hiệu hóa thành phần không cần thiết
Nếu không có nhu cầu sử dụng, dừng KSMBD và ngăn tự động kích hoạt lại theo quy trình quản trị của hệ thống. Với dịch vụ đang phục vụ nghiệp vụ, cần đánh giá ảnh hưởng và chuẩn bị phương án chuyển đổi trước khi thay đổi.
3. Giới hạn truy cập SMB và đường truyền RDMA
Chặn truy cập SMB trực tiếp từ Internet, chỉ cho phép các nguồn thực sự cần thiết và áp dụng phân đoạn mạng. Với SMB Direct, cần rà soát riêng đường truyền RDMA; không nên mặc định quy tắc chặn TCP 445 đã bao phủ toàn bộ bề mặt tấn công.
4. Tăng cường giám sát và điều tra
Theo dõi kết nối SMB bất thường, sự cố kernel, cảnh báo truy cập bộ nhớ và các đợt gián đoạn dịch vụ khó giải thích. Kết hợp dữ liệu mạng với nhật ký hệ thống để đánh giá bối cảnh. Một lần kernel gặp lỗi không đủ để xác nhận bị tấn công, nhưng cần được điều tra nếu đi kèm lưu lượng đáng ngờ.
5. Theo dõi bản vá từ nhà cung cấp
Ưu tiên thông báo bảo mật và gói kernel do bản phân phối cung cấp. Sau cập nhật, xác nhận bản vá đã áp dụng cho kernel thực sự đang chạy và hoàn tất khởi động lại nếu quy trình yêu cầu.
VNCS Global: Chủ động kiểm soát rủi ro trong khoảng trống chờ bản vá
Khi thông tin kỹ thuật đã công khai nhưng bản cập nhật chưa sẵn sàng cho môi trường sản xuất, khả năng phòng thủ phụ thuộc vào mức độ hiểu rõ tài sản, kiểm soát truy cập và phát hiện bất thường của doanh nghiệp.
Kiểm soát phơi nhiễm ngay hôm nay, tăng khả năng phòng thủ trước những lỗ hổng chưa kịp vá. Kết nối với VNCS Global để đánh giá rủi ro và xây dựng phương án giám sát, ứng phó phù hợp cho hạ tầng của doanh nghiệp.
