CVE-2026-89612
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
ntfs: reject invalid MFT LCNs from boot sector
The NTFS boot sector stores the MFT and MFTMirr locations as unsigned 64-bit LCNs, but parse_ntfs_boot_sector() decoded them into an s64.
A crafted high-bit value could therefore become negative and pass the existing upper-bound check. The invalid value then propagated into the MFT zone allocator and could result in an out-of-bounds access to lcn_empty_bits_per_page.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified within the Linux kernel's NTFS filesystem driver stems from a fundamental type mismatch during the parsing of critical boot sector metadata. Specifically, the function parse_ntfs_boot_sector is responsible for reading the locations of the Master File Table and its mirror from the disk volume header. These location values are stored as unsigned 64-bit Logical Cluster Numbers in the file system structure on disk. However, the kernel implementation incorrectly decodes these fields into signed 64-bit integers using a s64 data type rather than an appropriate unsigned variant such as u64 or uint64_t. This discrepancy creates a critical arithmetic boundary condition where valid high-range address values are misinterpreted by the operating system's memory management and file system logic.
When a crafted NTFS volume contains MFT location fields with their most significant bit set, indicating a value greater than 2^63 minus one, the signed interpretation causes these large positive numbers to be treated as negative integers due to two's complement representation rules. The existing validation logic in the kernel relies on an upper-bound check to ensure that the parsed LCNs fall within acceptable limits for memory allocation and disk access. Because the value is now perceived as negative rather than a massive unsigned integer, it trivially passes this upper-bound verification step. Consequently, the invalid logical cluster number propagates further into the MFT zone allocator without triggering any error conditions or rejection mechanisms that would normally safeguard against out-of-bounds operations.
The operational impact of this flaw allows for an out-of-bounds memory access within the kernel space. The erroneous LCN value is subsequently used to index into lcn_empty_bits_per_page, a data structure responsible for tracking free clusters on the volume. Since the negative or erroneously interpreted large integer does not correspond to valid array indices in the expected manner, it can lead to reading from or writing to memory locations outside the allocated bounds of this structure. This out-of-bounds access poses severe security risks, including potential kernel panic leading to denial of service conditions where the system becomes unstable and requires a reboot. Furthermore, depending on the specific memory layout and what resides adjacent to lcn_empty_bits_per_page in physical or virtual memory, an attacker could potentially leverage this flaw for arbitrary code execution by overwriting critical kernel data structures or control flow pointers.
This vulnerability is classified under CWE-190 Integer Overflow resulting in a negative value which bypasses bounds checks, closely related to CWE-787 Out-of-bounds Write and CWE-788 Out-of-bounds Read depending on the exact memory access pattern exploited during exploitation attempts. From an ATT&CK perspective, this aligns with techniques involving kernel exploitation for privilege escalation or persistence if the out-of-bounds write can be controlled sufficiently to modify execution flow. The root cause is a classic implementation error where data type selection does not match the source specification of the file system format being parsed.
To mitigate this vulnerability and prevent similar issues in future code, it is imperative that developers strictly adhere to the data types defined by the NTFS specification when parsing boot sector structures. Changing the variable type from s64 to u64 ensures that high-bit values are preserved as large positive integers rather than negative numbers. Additionally, validation logic should be updated to explicitly check for maximum valid LCN limits appropriate for the specific volume size and file system constraints, ensuring that even unsigned values do not exceed reasonable bounds before being used in memory allocation or indexing operations. Regular static analysis tools configured to detect signed-unsigned mismatches can also help identify such discrepancies during the development lifecycle.