0.0
NA
CVE-2026-90200
fs/ntfs3: fix integer overflow in MFT cluster validation
Description

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.

INFO

Published Date :

Sept. 17, 2026, 5:17 p.m.

Last Modified :

Sept. 17, 2026, 5:17 p.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2026-90200 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel
Solution
Fix integer overflow in MFT cluster validation to prevent incorrect MFT records from being accepted.
  • Apply the kernel patch for the ntfs3 module.
  • Update the Linux kernel to a fixed version.
  • Recompile the kernel with the security fix.
  • Validate MFT cluster numbers using overflow checks.
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-90200 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-90200 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2026-90200 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2026-90200 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Sep. 17, 2026

    Action Type Old Value New Value
    Added Description 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.
    Added Affected New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/90xxx/CVE-2026-90200.json">CVE-2026-90200</a>
    Added Reference https://git.kernel.org/stable/c/169383d8914b8fe03464a83540b5b6de3e7831af
    Added Reference https://git.kernel.org/stable/c/805cc5554b13d045dce9b03c13eaf015418739fd
    Added Reference https://git.kernel.org/stable/c/c510c63873103a5da6a498fe537bdb5d6f8d03a2
    Added Reference https://git.kernel.org/stable/c/dc6d85de7e2656e56e10ff5ba514f2583a4f612b
    Added Reference https://git.kernel.org/stable/c/f77a8d9fdf58e298b36564a44c27fadc617bdd28
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.