Cloudanix VulnDB

CVE-2026-89617

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux handles certain NTFS disk structures during recovery could let someone with local access corrupt the system kernel by attaching a specially made drive image.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Unchecked lcns_follow field in DIR_PAGE_ENTRY allows memmove and replay operations to read or write past the allocated entry boundary during NTFS3 log replay in the Linux kernel.

Why it matters to the business

Local users or attackers with access to mount untrusted NTFS volumes can trigger kernel memory corruption, potentially leading to system crashes, privilege escalation, or data compromise on affected Linux systems.

How an attack unfolds

An attacker prepares a crafted NTFS filesystem containing a DIR_PAGE_ENTRY with an oversized lcns_follow value. When the volume is mounted, the kernel performs log replay, check_rstbl succeeds, and subsequent accesses via v0-to-v1 conversion memmove, find_dp, or scan loops overflow the entry, corrupting adjacent kernel memory.

How to fix it

Apply the upstream kernel patch that introduces check_dp_table immediately after check_rstbl to enforce struct_size bounds on every DIR_PAGE_ENTRY before any lcns_follow-indexed access.

How to confirm the fix worked

Confirm presence of check_dp_table call and struct_size validation in fs/ntfs3/logfile.c after the published fix date; test by attempting to mount a volume with an intentionally oversized lcns_follow entry and verify rejection.

Typical attack path

  1. Craft malicious NTFS volume with oversized page_lcns array in dirty page table entry
  2. Trigger mount or log replay on target Linux system
  3. Bypass check_rstbl validation
  4. Execute out-of-bounds memmove or replay writes
  5. Achieve kernel memory corruption for code execution or denial of service

How to detect it

Inspect kernel logs for ntfs3 log replay entries followed by out-of-bounds access oops; review auditd or system call traces for unexpected mount operations on NTFS volumes from untrusted sources.

What your security team should do

  • Prioritize kernel updates containing the ntfs3 log replay bounds check for all systems that mount NTFS volumes
  • Restrict untrusted NTFS mounts via mount options or SELinux/AppArmor policies until patched
  • Monitor kernel logs for ntfs3-related oops or warnings during volume attachment

The record

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.

Affected packages

Ecosystem Package Introduced Fixed