CVE-2026-90200 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: fix integer overflow in MFT cluster validation
In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with:
if (mlcn * sct_per_clst >= sectors || mlcn2 * sct_per_clst >= sectors) goto out;
mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted.
The accepted mlcn is then used unchanged in
sbi->mft.lbo = mlcn << cluster_bits;
In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place.
Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's NTFS3 filesystem driver contains an integer overflow vulnerability within its Master File Table cluster validation logic, specifically located in the ntfs_init_from_boot function. This flaw arises during the processing of boot sector data where two unsigned 64-bit fields, mlcn and mlcn2, representing MFT cluster numbers are read directly from disk structures. These values undergo a multiplication operation with sct_per_clst to determine their corresponding sector positions on the volume. The variable sct_per_clst represents sectors per cluster and is bounded by a maximum value of 4096 due to internal power-of-two checks. However, because both operands are treated as unsigned 64-bit integers, the multiplication result can exceed the maximum representable value for u64, causing an arithmetic wraparound or overflow condition rather than triggering an error immediately.
The core technical flaw lies in the validation check that compares the product of mlcn and sct_per_clst against the total number of sectors on the volume. When a crafted boot sector contains large values for mlcn or mlcn2, such as values near 2^62 combined with a cluster size multiplier like four, the resulting multiplication wraps around to zero or another small value. This wrapped result is numerically smaller than the actual volume size in sectors, causing the conditional check to evaluate as false and allowing the malformed record to be accepted by the filesystem driver. Consequently, the invalid mlcn value proceeds through subsequent processing steps without triggering an immediate rejection based on out-of-bounds criteria at this stage of initialization.
The operational impact involves the use of the unchecked cluster number in calculating the logical block offset for the MFT via a left shift operation involving cluster bits. While the current implementation often results in mount failures due to downstream safeguards, such as checks within grow_buffers that detect multiplication overflows during buffer allocation, this reliance on secondary validation layers is insufficient from a security perspective. The primary vulnerability allows malformed data structures to bypass initial integrity checks, potentially leading to undefined behavior or crashes if future code paths rely on the assumption that mlcn values have been strictly validated against volume boundaries at this specific point in execution. Although immediate exploitation for arbitrary code execution may be limited by block layer protections, the presence of unchecked arithmetic operations remains a significant defect in input validation logic.
To remediate this vulnerability, the kernel developers implemented a fix utilizing check_mul_overflow to explicitly detect when the multiplication of mlcn or mlcn2 with sct_per_clst exceeds the limits of unsigned 64-bit integers. This approach ensures that any potential overflow condition causes the mount operation to fail immediately and safely, rather than allowing wrapped values to propagate through the system. The solution preserves existing semantic comparisons by failing on overflow before performing the comparison against sector counts, maintaining consistency with other arithmetic safety checks already present in the ntfs3 driver codebase. This method avoids switching to division-based validation which could introduce edge case errors when volume sizes are not exact multiples of cluster sizes.
From a classification standpoint, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-20 Improper Input Validation within industry standard taxonomies. The attack vector involves providing maliciously crafted on-disk metadata structures that exploit the lack of overflow detection during arithmetic operations on user-controlled input derived from disk sectors. In terms of adversary tactics, this relates to ATT&CK techniques involving exploitation for denial of service or potential privilege escalation if similar unchecked arithmetic patterns exist in other kernel components handling external inputs. The fix reinforces best practices by ensuring that all arithmetic operations involving values derived directly from untrusted storage media are validated against overflow conditions before being used in memory address calculations or boundary checks, thereby hardening the filesystem driver against malformed input attacks.