Cloudanix VulnDB

CVE-2026-98138

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux NTFS driver can hide filesystem problems so they are never fixed, raising the chance of unnoticed data damage on affected computers.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The ntfs_sync_fs function unconditionally clears the volume dirty bit even when NVolErrors(vol) is true, allowing a filesystem with recorded errors such as mismatched $MFT/$MFTMirr to be marked clean on sync and thereby skip recovery on subsequent mounts.

Why it matters to the business

Unrepaired filesystem inconsistencies can persist across remounts, increasing the risk of data corruption or loss on Linux systems using NTFS volumes without any external indicators of the problem.

How an attack unfolds

An attacker with local write access to an NTFS volume triggers an error condition that sets the internal error flag, issues a write followed by sync, and leaves the on-disk volume flags indicating a clean state so that recovery is skipped on next mount, allowing latent corruption to remain undetected.

How to fix it

Apply the upstream kernel patch that adds a check for NVolErrors before clearing the dirty bit in ntfs_sync_fs; rebuild and deploy the fixed kernel to all affected systems.

How to confirm the fix worked

Confirm the presence of the error-flag guard in ntfs_sync_fs source, reproduce the $MFTMirr mismatch scenario, and verify that post-sync volume flags retain the dirty bit when errors were recorded.

Typical attack path

  1. Obtain local access to a system mounting an NTFS volume
  2. Perform operations that cause an NTFS error condition to be recorded
  3. Trigger a sync operation on the volume
  4. Unmount and remount the volume to observe skipped recovery

How to detect it

Review kernel logs for NTFS error flags being set, followed by sync activity and subsequent mounts without recovery messages; inspect volume metadata for unexpected clean flags after known errors.

What your security team should do

  • Prioritize kernel updates for any systems mounting NTFS volumes
  • Audit logs for prior sync operations on volumes that later show inconsistency
  • Consider read-only remount policies for high-value NTFS data stores until patched

The record

In the Linux kernel, the following vulnerability has been resolved: ntfs: do not mark the volume clean in sync_fs when errors were recorded ntfs_put_super() and the remount-read-only path both clear the dirty bit only when NVolErrors(vol) is false. ntfs_sync_fs() clears it unconditionally, so any sync() on a volume that recorded an error marks that volume clean. A volume without this set is then seen as not needing recovery and it does not run one, so whatever went wrong is never repaired. This change skips resetting the dirty bit when there are volume errors. Reproduced on a volume whose $MFTMirr does not match $MFT, which sets the error flag while leaving the mount read-write: after a write and a sync, the on-disk volume flags read 0x0000 with this driver and 0x0001 with the guard in place.

Affected packages

Ecosystem Package Introduced Fixed