HIGH Introduced in 7.1
ntfs MftRecord Race
CVE-2026-90131
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
KernelScan AI6.2MEDIUM
01Description
In the Linux kernel, the following vulnerability has been resolved: ntfs: serialize resident iomap reads with mrec_lock ntfs_read_iomap_begin_resident() walks the MFT record through ntfs_attr_lookup() -> ntfs_attr_find() without taking ni->mrec_lock, while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and ntfs_resident_attr_record_add() memmove() the same base_ni->mrec buffer under that lock. map_mft_record() only takes a reference and does not serialize, so the reader can observe torn attribute length and offset fields while a writer is relocating the records. KCSAN reports the race between the mmap read fault path and both link() and unlink(): BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize write to 0xffff888100af1018 of 4 bytes by task 96 on cpu 1: ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520 read to 0xffff888100af1018 of 4 bytes by task 95 on cpu 0: ntfs_attr_find+0x104/0x5b0 ntfs_attr_lookup+0x39c/0x10c0 ntfs_read_iomap_begin_resident+0xc6/0x230 ntfs_read_iomap_begin+0x5d/0xa0 iomap_iter+0x2e2/0x6e0 iomap_read_folio+0x147/0x2a0 ntfs_read_folio+0x108/0x170 filemap_read_folio+0x35/0x100 filemap_fault+0x993/0x1000 value changed: 0x00000250 -> 0x000001f0 The address is mrec + 0x18, i.e. mft_record.bytes_in_use, and the change is the 96 bytes of one $FILE_NAME attribute being removed. Keep base_ni->mrec_lock from the resident read iomap lookup through iomap_end(). This protects both the attribute walk and the subsequent copy from iomap->inline_data, which points into the MFT record. The non-resident path is left alone: ntfs_lookup() already holds the directory inode's mrec_lock when it reads an index folio through read_mapping_folio(), and taking the lock in the shared wrapper deadlocks there with recursive locking on mrec_lock. The comment above the read_mapping_folio() call in fs/ntfs/dir.c notes the same hazard. The seek path uses the same lookup helper but does not dereference iomap->inline_data. Release the lock before returning from that path, whereas the regular read path records base_ni in iomap->private and releases the lock from its iomap_end() callback. Tested with a reproducer that faults in a 16-byte resident file while another thread runs link()/unlink() on it. Before: 40 KCSAN reports in about one second. After: no reports in 180 seconds over 206,090 read iterations and 423,540 link/unlink cycles. A PROVE_LOCKING build shows no lockdep splat with the same reproducer running for 60 seconds.
02KernelScan AI Analysis
Risk summary
A local attacker with ordinary file access on a mounted NTFS volume can exploit a race between memory-mapped file reads and link/unlink operations to observe torn MFT record metadata, potentially causing out-of-bounds reads, information disclosure, or kernel panic. Exploitation requires precise timing to win the race window but needs no special kernel privileges beyond normal filesystem permissions.
Vulnerability analysis
A race condition in the NTFS filesystem allows a thread reading a small resident file to inspect the file's record metadata while another thread is modifying it. Because the reader does not hold the lock that protects the metadata buffer, it can see partially-updated length and offset values while attributes are being relocated. This leads the reader to access memory outside the intended data area, potentially leaking kernel heap contents or triggering a kernel panic. The fix makes the reader acquire the same protection lock before examining the record and hold it until the data copy completes; a path that only queries file position releases the lock earlier because it never touches the actual data. An attacker can trigger this by performing memory-mapped reads on a resident file while simultaneously creating or removing hard links to it on a mounted NTFS volume, requiring only ordinary local file access.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 7.2 | 7.1 | 7.2.6 | 0400e0d50eb3 |
| mainline | 7.1 | 7.3-rc1 | d9e00c457d4a |