CVE-2026-90117: ntfs: validate usa_ofs before preserving the update sequence number
In the Linux kernel, the following vulnerability has been resolved:
ntfs: validate usaofs before preserving the update sequence number
When ntfsmftrecordalloc() reuses a free mft record it reads the old update sequence number straight from the on-disk record:
usn = (le16 )((u8 )m + le16tocpu(m->usaofs));
Here m points into the raw $MFT page-cache folio, which still holds unvalidated, MST-protected bytes: the folio is read by a plain iomapreadfolio() and neither postreadmstfixup() nor ntfsmftrecordcheck() has run on it (both work on private copies). m->usaofs is therefore an untrusted u16, and a corrupted record can put it past the end of the record so the two-byte read lands outside the folio. Reading such a record while creating a file gives, under KASAN:
BUG: KASAN: use-after-free in ntfsmftrecordalloc+... Read of size 2 at addr ... ntfsmftrecordalloc -> ntfscreate -> ntfscreate -> pathopenat
Only preserve the old update sequence number when usaofs is even and in range, mirroring the check ntfsmftrecordcheck() already applies; otherwise leave usn zero, which the existing restore below skips.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the resolved NTFS fix so that ntfs_mft_record_alloc() preserves the old update sequence number only when usa_ofs is even; validate usa_ofs before using it for the two-byte read from m at m->usa_ofs (the MST-protected update sequence number).
Linux kernel (NTFS: ntfs_mft_record_alloc) ntfs: validate usa_ofs before preserving the update sequence number = Ensure usa_ofs is even before preserving the old update sequence number; otherwise leave usn zero
Event History
Frequently Asked Questions
What conditions are required to trigger the issue?
A corrupted NTFS MFT record must be reused while the kernel is creating a file. The record's untrusted update-sequence-array offset must cause the kernel's two-byte read to fall beyond the raw $MFT page-cache folio.
Are systems using ordinary, valid NTFS filesystems affected?
The described out-of-bounds read depends on a corrupted on-disk MFT record. The data does not indicate that a valid NTFS filesystem triggers the condition.
What should be done if the fix cannot be applied immediately?
Avoid creating files on NTFS filesystems with suspected corruption. The issue is reached during file creation when a free MFT record is reused.
How can an affected system be identified?
With KASAN enabled, the reported symptom is a use-after-free report in ntfs_mft_record_alloc during a file-creation path, such as ntfs_mft_record_alloc -> __ntfs_create -> ntfs_create -> path_openat.