Cloudanix VulnDB

CVE-2026-98140

None

CVSS

—

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's handling of NTFS file writes can leave internal memory mappings active on failure, which may cause the system to become unstable or crash.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability leaves a kmap_local_folio mapping active on certain error paths in write_mft_record_nolock(), violating stack-ordered nesting rules for per-task kmap_local mappings and thereby corrupting any outer mappings performed by the same task.

Why it matters to the business

Linux systems that mount NTFS volumes may experience unpredictable kernel memory corruption, leading to crashes, data loss, or service outages; the issue is present in the mainline kernel and distributions that have not yet applied the fix.

How an attack unfolds

An attacker would need to trigger repeated write operations to the NTFS MFT that hit the pre_write_mst_fixup or bio_add_folio failure paths while other code in the same task holds outer kmap_local mappings, gradually corrupting the mapping state until the system becomes unstable or an attacker-controlled fault occurs.

How to fix it

Apply the upstream patch that adds the missing kmap_local unmap calls on the error paths; rebuild and deploy the fixed kernel to all affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting the write_mft_record_nolock function for the added unmap calls before the error label; run regression tests that exercise the error paths in write_mft_record_nolock.

Typical attack path

  1. Mount an NTFS volume on a vulnerable kernel
  2. Induce write_mft_record_nolock calls that encounter the specific error paths
  3. Repeat while other kernel code holds nested kmap_local mappings
  4. Observe or trigger memory corruption or kernel panic

How to detect it

Review kernel logs and dmesg for oops or panic messages referencing kmap_local or write_mft_record_nolock; examine ftrace or perf traces around NTFS MFT write operations for unexpected mapping state.

What your security team should do

  • Prioritize kernel updates for any systems that mount NTFS volumes
  • Monitor kernel crash logs for symptoms consistent with kmap_local nesting violations
  • Restrict untrusted code from performing heavy NTFS write workloads until patched

The record

In the Linux kernel, the following vulnerability has been resolved: ntfs: fix kmap_local leak in write_mft_record_nolock() error paths write_mft_record_nolock() maps the MFT record folio with kmap_local_folio(), but the pre_write_mst_fixup() and bio_add_folio() failure paths jump to the error label without unmapping it. kmap_local mappings are stack-ordered per task, so leaking one corrupts the nesting for any outer mapping. Unmap the folio on those error paths too.

Affected packages

Ecosystem Package Introduced Fixed