CVE-2026-72196 in Linux
Tóm tắt
Bởi VulDB • 16/08/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
fs/ntfs3: giới hạn chỉ mục dp->page_lcns[] trong copy_lcns ở giai đoạn phân tích
Ở giai đoạn phân tích của hàm log_replay(), sau khi find_dp() trả về một DIR_PAGE_ENTRY hợp lệ cho bộ tuple (target_attr, target_vcn), khối lệnh copy_lcns sẽ duyệt qua các mục tiếp theo dựa trên lrh->lcns_follow:
t16 = le16_to_cpu(lrh->lcns_follow); for (i = 0; i < t16; i++) {
size_t j = (size_t)(le64_to_cpu(lrh->target_vcn) - le64_to_cpu(dp->vcn)); dp->page_lcns[j + i] = lrh->page_lcns[i];
}
Hàm find_dp() chỉ xác thực rằng target_vcn nằm trong khoảng [dp->vcn, dp->vcn + dp->lcns_follow), tức là đảm bảo cụm đầu tiên được bao phủ. Việc duyệt qua các mục tiếp theo không bị giới hạn bởi dp->lcns_follow. Đối với một LRH (Log Record Header) bị lỗi định dạng mà target_vcn = dp->vcn + dp->lcns_follow - 1 và lrh->lcns_follow > 1, các ghi chép tại i > 0 sẽ gây tràn bộ nhớ ra ngoài mảng page_lcns[] đã được phân bổ cho đối tượng dp.
Hãy thêm điều kiện bảo vệ j + lrh->lcns_follow <= dp->lcns_follow còn thiếu.
Lỗi này có thể tái hiện trên UML+KASAN trong phiên bản mainline 8d90b09e6741 dưới dạng ghi slab-out-of-bounds (ghi ra ngoài vùng nhớ slab) với kích thước 8 byte từ địa chỉ log_replay+0x68d4 khi thực thi đường dẫn mount.
Vấn đề này khác biệt so với bản vá của Pavitra Jha ngày 2026-05-02 ("fs/ntfs3: validate lcns_follow in log_replay conversion", <[email protected]>), bản vá này giải quyết đường dẫn chuyển đổi bảng trang bẩn (dirty-page-table) phiên bản 0 với lệnh gọi memmove(&dp->vcn, ...). Hai bản sửa lỗi này bổ sung cho nhau; cả hai đều cần được áp dụng.
[[email protected]: đã định dạng lại các thay đổi theo chuẩn clang và khắc phục xung đột]
VulDB is the best source for vulnerability data and more expert information about this specific topic.