CVE-2026-89615

What it actually does

Out-of-bounds write to the page_lcns array in the ntfs3 driver when processing a crafted log record whose lcns_follow value exceeds the validated bounds of the target entry, allowing an attacker-controlled index to overwrite adjacent kernel memory.

Why it matters to the business

Local attackers on systems that mount untrusted NTFS volumes can achieve kernel memory corruption, potentially leading to privilege escalation, system crashes, or arbitrary code execution; the low EPSS and lack of known exploitation reduce immediate urgency but the high CVSS reflects severe local impact if triggered.

How an attack unfolds

An attacker prepares a malicious NTFS volume containing a crafted log record with an oversized lcns_follow field. When the kernel processes the record via copy_lcns or the redo shorten loop, the unchecked index j + i overflows page_lcns of a valid entry, corrupting kernel memory. No named threat actors or ransomware campaigns are associated with this issue.

How to fix it

Update to a Linux kernel containing the fix that introduces dp_range_ok checks before the copy_lcns and redo shorten loops. Rebuild and reboot systems using the ntfs3 driver. Until patched, avoid mounting untrusted NTFS volumes with the ntfs3 driver.

How to confirm the fix worked

Confirm the kernel source contains the dp_range_ok addition and that both copy_lcns and redo shorten loops are guarded before indexing page_lcns by the record. Test by attempting to mount a crafted image that previously triggered the overflow and verify the operation is rejected.

Typical attack path

1. Obtain local access or ability to supply an untrusted NTFS image
2. Create or modify an NTFS volume with a specially crafted log record that passes entry validation but violates dp_range_ok checks
3. Mount the volume or trigger log replay on the target system
4. Trigger the copy_lcns or redo loop to perform the out-of-bounds write
5. Leverage the resulting kernel memory corruption for privilege escalation or denial of service

How to detect it

Monitor kernel logs for ntfs3-related oops or warnings during volume mount or log replay. No public exploitation artifacts are known; look for unexpected page allocation failures or memory corruption symptoms in dmesg after NTFS operations.

What your security team should do

• Prioritize patching systems that expose the ntfs3 driver to untrusted media
• Monitor upstream kernel releases for the backported fix
• Consider blacklisting or restricting ntfs3 until updated kernels are deployed
• Review mount policies and limit use of the ntfs3 driver to trusted volumes only