CVE-2026-89615 (CVSS 8.4)

Description

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [[email protected]: original patch contained changes to the problem already handled, applied partly]

Is your site exposed to CVE-2026-89615?

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

CVSS v3.1 Score

8.4

HIGH

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

EPSS — Exploit Prediction

0.0015

Probability of exploitation

0.05%

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/1135ebc225996b3ac1a295652b19a0a706737a6c https://git.kernel.org/stable/c/31fdd11f75da9823500168cecb07aa45130915a3 https://git.kernel.org/stable/c/61ca8cbbf68f77f25b699ed4358bd232f94ed43b https://git.kernel.org/stable/c/6f7b9dbdc1b7520206abce0049bdd143eb536e75 https://git.kernel.org/stable/c/7ccb94901f38a062034b56b43c774050b113758f https://git.kernel.org/stable/c/bb742d1030864c0fe140666f639428ba4e90b2ca https://git.kernel.org/stable/c/f4c1bc6d7331f344ffcea93c2a37badcbe15baa6

Frequently Asked Questions

What is CVE-2026-89615? +

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [[email protected]: original patch contained changes to the problem already handled, applied partly] It has a CVSS v3.1 base score of 8.4 (HIGH).

How severe is CVE-2026-89615? +

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

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

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-89615