Answer in brief
CVE-2026-89615 records a High severity (CVSS 8.4) vulnerability in fs/ntfs3: bound page_lcns[] index by the log record. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.4. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b46acd6a6a627d876898e1c84d3f84902264b445 <f4c1bc6d7331f344ffcea93c2a37badcbe15baa6 || >=b46acd6a6a627d876898e1c84d3f84902264b445 <7ccb94901f38a062034b56b43c774050b113758f || >=b46acd6a6a627d876898e1c84d3f84902264b445 <1135ebc225996b3ac1a295652b19a0a706737a6c || >=b46acd6a6a627d876898e1c84d3f84902264b445 <6f7b9dbdc1b7520206abce0049bdd143eb536e75 | f4c1bc6d7331f344ffcea93c2a37badcbe15baa6, 7ccb94901f38a062034b56b43c774050b113758f, 1135ebc225996b3ac1a295652b19a0a706737a6c, 6f7b9dbdc1b7520206abce0049bdd143eb536e75 |
| Linux/Linuxgeneric | 5.15 | Not reported |
| Linux/Linuxgeneric | >=b46acd6a6a627d876898e1c84d3f84902264b445 <31fdd11f75da9823500168cecb07aa45130915a3 || >=b46acd6a6a627d876898e1c84d3f84902264b445 <bb742d1030864c0fe140666f639428ba4e90b2ca || >=b46acd6a6a627d876898e1c84d3f84902264b445 <61ca8cbbf68f77f25b699ed4358bd232f94ed43b || >=b46acd6a6a627d876898e1c84d3f84902264b445 <f4c1bc6d7331f344ffcea93c2a37badcbe15baa6 || >=b46acd6a6a627d876898e1c84d3f84902264b445 <7ccb94901f38a062034b56b43c774050b113758f || >=b46acd6a6a627d876898e1c84d3f84902264b445 <1135ebc225996b3ac1a295652b19a0a706737a6c || >=b46acd6a6a627d876898e1c84d3f84902264b445 <6f7b9dbdc1b7520206abce0049bdd143eb536e75 | 31fdd11f75da9823500168cecb07aa45130915a3, bb742d1030864c0fe140666f639428ba4e90b2ca, 61ca8cbbf68f77f25b699ed4358bd232f94ed43b, f4c1bc6d7331f344ffcea93c2a37badcbe15baa6, 7ccb94901f38a062034b56b43c774050b113758f, 1135ebc225996b3ac1a295652b19a0a706737a6c, 6f7b9dbdc1b7520206abce0049bdd143eb536e75 |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 11, 2026
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]
Quoted source text, attributed separately from HOL analysis.