{"api_version":"1","generated_at":"2026-09-25T12:40:15+00:00","cve":"CVE-2026-98138","urls":{"html":"https://cve.report/CVE-2026-98138","api":"https://cve.report/api/cve/CVE-2026-98138.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-98138","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-98138"},"summary":{"title":"ntfs: do not mark the volume clean in sync_fs when errors were recorded","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: do not mark the volume clean in sync_fs when errors were recorded\n\nntfs_put_super() and the remount-read-only path both clear the dirty bit\nonly when NVolErrors(vol) is false. ntfs_sync_fs() clears it\nunconditionally, so any sync() on a volume that recorded an error marks\nthat volume clean. A volume without this set is then seen as not needing\nrecovery and it does not run one, so whatever went wrong is never repaired.\n\nThis change skips resetting the dirty bit when there are volume errors.\n\nReproduced on a volume whose $MFTMirr does not match $MFT, which sets the\nerror flag while leaving the mount read-write: after a write and a sync,\nthe on-disk volume flags read 0x0000 with this driver and 0x0001 with the\nguard in place.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-25 11:17:45","updated_at":"2026-09-25 11:17:45"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/0e4c839905418d55bafe571a92533a1d1ac7b0a8","name":"https://git.kernel.org/stable/c/0e4c839905418d55bafe571a92533a1d1ac7b0a8","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/ca1f9933eff777a604eb664d0f9ae433b8664cbf","name":"https://git.kernel.org/stable/c/ca1f9933eff777a604eb664d0f9ae433b8664cbf","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-98138","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98138","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6251f0b0de7d645e3591931ca4c11d8322c1866f ca1f9933eff777a604eb664d0f9ae433b8664cbf git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6251f0b0de7d645e3591931ca4c11d8322c1866f 0e4c839905418d55bafe571a92533a1d1ac7b0a8 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7.1","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.7 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc2 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/ntfs/super.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"ca1f9933eff777a604eb664d0f9ae433b8664cbf","status":"affected","version":"6251f0b0de7d645e3591931ca4c11d8322c1866f","versionType":"git"},{"lessThan":"0e4c839905418d55bafe571a92533a1d1ac7b0a8","status":"affected","version":"6251f0b0de7d645e3591931ca4c11d8322c1866f","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/ntfs/super.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"7.1"},{"lessThan":"7.1","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.7","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc2","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.7","versionStartIncluding":"7.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc2","versionStartIncluding":"7.1","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: do not mark the volume clean in sync_fs when errors were recorded\n\nntfs_put_super() and the remount-read-only path both clear the dirty bit\nonly when NVolErrors(vol) is false. ntfs_sync_fs() clears it\nunconditionally, so any sync() on a volume that recorded an error marks\nthat volume clean. A volume without this set is then seen as not needing\nrecovery and it does not run one, so whatever went wrong is never repaired.\n\nThis change skips resetting the dirty bit when there are volume errors.\n\nReproduced on a volume whose $MFTMirr does not match $MFT, which sets the\nerror flag while leaving the mount read-write: after a write and a sync,\nthe on-disk volume flags read 0x0000 with this driver and 0x0001 with the\nguard in place."}],"providerMetadata":{"dateUpdated":"2026-09-25T10:36:15.349Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/ca1f9933eff777a604eb664d0f9ae433b8664cbf"},{"url":"https://git.kernel.org/stable/c/0e4c839905418d55bafe571a92533a1d1ac7b0a8"}],"title":"ntfs: do not mark the volume clean in sync_fs when errors were recorded","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-98138","datePublished":"2026-09-25T10:36:15.349Z","dateReserved":"2026-09-25T10:25:14.319Z","dateUpdated":"2026-09-25T10:36:15.349Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-25 11:17:45","lastModifiedDate":"2026-09-25 11:17:45","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"98138","Ordinal":"1","Title":"ntfs: do not mark the volume clean in sync_fs when errors were r","CVE":"CVE-2026-98138","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"98138","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: do not mark the volume clean in sync_fs when errors were recorded\n\nntfs_put_super() and the remount-read-only path both clear the dirty bit\nonly when NVolErrors(vol) is false. ntfs_sync_fs() clears it\nunconditionally, so any sync() on a volume that recorded an error marks\nthat volume clean. A volume without this set is then seen as not needing\nrecovery and it does not run one, so whatever went wrong is never repaired.\n\nThis change skips resetting the dirty bit when there are volume errors.\n\nReproduced on a volume whose $MFTMirr does not match $MFT, which sets the\nerror flag while leaving the mount read-write: after a write and a sync,\nthe on-disk volume flags read 0x0000 with this driver and 0x0001 with the\nguard in place.","Type":"Description","Title":"ntfs: do not mark the volume clean in sync_fs when errors were r"}]}}}