CVE-2026-89617 (CVSS 7.8)

Description

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.

Is your site exposed to CVE-2026-89617?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

7.8

HIGH

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS — Exploit Prediction

0.0014

Probability of exploitation

0.04%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

References

Other References

https://git.kernel.org/stable/c/006cb7713dec10368e699abc4367e5faa334c9a5 https://git.kernel.org/stable/c/0908da07c23be4f94b99dfd9a94765525f0fe4bd https://git.kernel.org/stable/c/0e07ea2fc45a7b4757ef7bf1f692cc0180a08323 https://git.kernel.org/stable/c/1200c2779c43b62656ccbb67df9468a7a9af2484 https://git.kernel.org/stable/c/1e90b1703ee1a04cd3e9e399353fc536f5f3ba10 https://git.kernel.org/stable/c/2d94ffc9d7b5bb3517b129fe63b52d84bcd4ae56 https://git.kernel.org/stable/c/d23155634a4bc1183e761d5eb2c043b2e693cc98

Frequently Asked Questions

What is CVE-2026-89617? +

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch. It has a CVSS v3.1 base score of 7.8 (HIGH).

How severe is CVE-2026-89617? +

CVE-2026-89617 has a CVSS v3.1 score of 7.8 out of 10, rated HIGH. This is a high-severity vulnerability that should be prioritized for patching. The EPSS score is 0.0014, placing it in the 0th percentile for exploitation probability.

How do I check if I'm vulnerable to CVE-2026-89617? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

CVE-2026-89617