CVE-2026-90200 in Linux
Tóm tắt
Bởi VulDB • 18/09/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
fs/ntfs3: sửa lỗi tràn số nguyên (integer overflow) trong quá trình xác thực cụm MFT
Hàm `ntfs_init_from_boot()` kiểm tra các số lượng cụm MFT của phân vùng khởi động so với kích thước khối dữ liệu bằng cách sử dụng đoạn mã sau:
if (mlcn * sct_per_clst >= sectors || mlcn2 * sct_per_clst >= sectors) goto out;
`mlcn` và `mlcn2` là các trường kiểu u64 được đọc trực tiếp từ phân vùng khởi động. `sct_per_clst` có giá trị tối đa là 4096 (true_sectors_per_clst() cộng với kiểm tra is_power_of_2() ở phía dưới), nhưng phép nhân được thực hiện trên kiểu dữ liệu u64 và bị tràn khi `mlcn` (hoặc `mlcn2`) đủ lớn -- ví dụ: `mlcn` gần bằng 2^62 trong trường hợp sct_per_clst == 1 sẽ bị tràn về 0, giá trị này nhỏ hơn bất kỳ 'sectors' nào khác không phải là số 0, do đó kiểm tra bị bỏ qua và bản ghi lỗi được chấp nhận.
Giá trị `mlcn` sau khi được chấp nhận sau đó được sử dụng nguyên vẹn trong:
sbi->mft.lbo = mlcn << cluster_bits;
Trong thực tế, các thao tác đọc kết quả sẽ thất bại ở lớp khối (block layer) (`sb_bread()` trả về NULL thông qua kiểm tra `check_mul_overflow()` của hàm `grow_buffers()`), do đó hiện tượng này ngày nay thể hiện dưới dạng việc gắn kết hệ thống tệp (mount) bị lỗi tại những vị trí kỳ lạ thay vì gây ra các hậu quả nguy hiểm hơn, nhưng bước xác thực vẫn chưa đúng và không có lý do gì để các caller dựa vào lớp khối để bắt một giá trị lẽ ra không bao giờ được chấp nhận ngay từ đầu.
Sử dụng `check_mul_overflow()` để tính toán hai vị trí sector và làm cho việc gắn kết hệ thống tệp thất bại nếu bất kỳ phép nhân nào bị tràn; điều này bảo toàn ngữ nghĩa hiện có (mlcn * sct_per_clst >= sectors) thay vì chuyển sang sử dụng phép chia (mlcn >= sectors / sct_per_clst), vốn sẽ siết chặt kiểm tra ở các trường hợp biên khi 'sectors' không phải là bội số của `sct_per_clst`. Phong cách `check_*_overflow()` là phong cách mà ntfs3 đã sử dụng cho các phép tính tương tự trên đĩa trong fs/ntfs3/run.c.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.