Answer in brief
CVE-2026-89617 records a Unknown severity vulnerability in fs/ntfs3: validate dirty page table on log replay. The current sources do not mark it as known exploited. The current feed maps 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.
A CVSS score is not reported in the current record. 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). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b46acd6a6a627d876898e1c84d3f84902264b445 <1200c2779c43b62656ccbb67df9468a7a9af2484 || >=b46acd6a6a627d876898e1c84d3f84902264b445 <2d94ffc9d7b5bb3517b129fe63b52d84bcd4ae56 || >=b46acd6a6a627d876898e1c84d3f84902264b445 <0908da07c23be4f94b99dfd9a94765525f0fe4bd || >=b46acd6a6a627d876898e1c84d3f84902264b445 <006cb7713dec10368e699abc4367e5faa334c9a5 | 1200c2779c43b62656ccbb67df9468a7a9af2484, 2d94ffc9d7b5bb3517b129fe63b52d84bcd4ae56, 0908da07c23be4f94b99dfd9a94765525f0fe4bd, 006cb7713dec10368e699abc4367e5faa334c9a5 |
| Linux/Linuxgeneric | 5.15 | Not reported |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 11, 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: 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.
Quoted source text, attributed separately from HOL analysis.