CVE-2026-98138: ntfs: do not mark the volume clean in sync_fs when errors were recorded
In the Linux kernel, the following vulnerability has been resolved:
ntfs: do not mark the volume clean in syncfs when errors were recorded
ntfsputsuper() and the remount-read-only path both clear the dirty bit only when NVolErrors(vol) is false. ntfssyncfs() 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 Software
Event History
Frequently Asked Questions
When is a system exposed to this issue?
The issue affects NTFS volumes mounted read-write by the Linux kernel NTFS driver when the volume has recorded errors. A subsequent sync can clear the on-disk dirty bit even though those errors remain unresolved.
What conditions can trigger the incorrect clean state?
An NTFS volume must first record an error while remaining mounted read-write, then receive a write followed by sync. The reported reproduction used a mismatch between $MFTMirr and $MFT.
What is the operational impact of the dirty bit being cleared?
The volume may be treated as not needing recovery, so recovery is not run and the underlying problem is not repaired. The description reports on-disk volume flags changing to 0x0000 after write and sync in the affected behavior.
How can an administrator check whether this behavior occurred?
For a volume that recorded an error, inspect its on-disk volume flags after a write and sync. A value of 0x0000 indicates the dirty bit was cleared; with the guard in place, the described error case retains 0x0001.