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.

[almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]
Published: 2026-09-11
Score: 6.7 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Privilege Escalation via Kernel Buffer Overflow
Action: Apply Patch
AI Analysis

Impact

The Linux kernel NTFS3 driver has an out‑of‑bounds write caused by improper bounds checking on the page_lcns array during the copy_lcns and redo loops. A crafted NTFS log record can overflow this array, corrupting kernel memory and potentially allowing an attacker with write access to the filesystem to execute privileged code or crash the system. This flaw corresponds to CWE‑787 Buffer Overflow.

Affected Systems

All Linux kernels that ship the unpatched NTFS3 implementation are affected. The vulnerability resides in the core kernel, so every distribution that includes the current kernel code is potentially vulnerable until the patch that introduces dp_range_ok() and the bounds check is applied. No specific version numbers are listed, so any kernel prior to the commit that applies the fix is considered vulnerable.

Risk and Exploitability

The CVSS score of 6.7 indicates moderate severity, while the EPSS score of less than 1% shows a low probability of exploitation. The flaw is not catalogued in the CISA KEV database, suggesting it has not yet been widely exploited in the wild. Successful exploitation would require the attacker to craft a malicious NTFS volume that the system processes, so it typically requires access to the filesystem rather than remote network access. Nevertheless, because the impact occurs in kernel space, a successful exploitation can lead to privilege escalation or a denial of service.

Generated by OpenCVE AI on September 13, 2026 at 01:36 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the ntfs3 bounds‑check fix committed by the patch.
  • If an immediate kernel upgrade cannot be performed, unmount or disable all NTFS3 filesystems or the ntfs3 module until the kernel is updated.
  • Alternatively, backport the specific commit changes (adding dp_range_ok() and bounds checks) to the running kernel or to the distribution’s kernel patches.

Generated by OpenCVE AI on September 13, 2026 at 01:36 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 12 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Sat, 12 Sep 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-787
References
Metrics threat_severity

None

cvssV3_1

{'score': 6.7, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Sat, 12 Sep 2026 09:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Fri, 11 Sep 2026 23:45:00 +0000

Type Values Removed Values Added
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. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]
Title fs/ntfs3: bound page_lcns[] index by the log record
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-11T19:45:15.397Z

Reserved: 2026-09-11T19:38:34.735Z

Link: CVE-2026-89615

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-11T20:19:46.653

Modified: 2026-09-11T20:19:46.653

Link: CVE-2026-89615

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-11T19:45:15Z

Links: CVE-2026-89615 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-13T01:45:07Z

Weaknesses