CVE-2026-90131

Status: UPDATED  |  Advisory ID: CVE-2026-90131

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References