In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ntfs: serialize resident iomap reads with mrec_lock<\/p>\n
ntfs_read_iomap_begin_resident() walks the MFT record through
\nntfs_attr_lookup() -> ntfs_attr_find() without taking ni->mrec_lock,
\nwhile ntfs_attr_record_resize(), ntfs_make_room_for_attr() and
\nntfs_resident_attr_record_add() memmove() the same base_ni->mrec buffer
\nunder that lock. map_mft_record() only takes a reference and does not
\nserialize, so the reader can observe torn attribute length and offset
\nfields while a writer is relocating the records.<\/p>\n
KCSAN reports the race between the mmap read fault path and both link()
\nand unlink():<\/p>\n
BUG: KCSAN: data-race in ntfs_attr_find \/ ntfs_attr_record_resize<\/p>\n
write to 0xffff888100af1018 of 4 bytes by task 96 on cpu 1:
\n ntfs_attr_record_resize+0xd2\/0x130
\n ntfs_attr_record_rm+0xad\/0x530
\n ntfs_delete+0x224\/0x640
\n ntfs_unlink+0x14d\/0x280
\n vfs_unlink+0x157\/0x520<\/p>\n
read to 0xffff888100af1018 of 4 bytes by task 95 on cpu 0:
\n ntfs_attr_find+0x104\/0x5b0
\n ntfs_attr_lookup+0x39c\/0x10c0
\n ntfs_read_iomap_begin_resident+0xc6\/0x230
\n ntfs_read_iomap_begin+0x5d\/0xa0
\n iomap_iter+0x2e2\/0x6e0
\n iomap_read_folio+0x147\/0x2a0
\n ntfs_read_folio+0x108\/0x170
\n filemap_read_folio+0x35\/0x100
\n filemap_fault+0x993\/0x1000<\/p>\n
value changed: 0x00000250 -> 0x000001f0<\/p>\n
The address is mrec + 0x18, i.e. mft_record.bytes_in_use, and the change
\nis the 96 bytes of one $FILE_NAME attribute being removed.<\/p>\n
Keep base_ni->mrec_lock from the resident read iomap lookup through
\niomap_end(). This protects both the attribute walk and the subsequent copy
\nfrom iomap->inline_data, which points into the MFT record. The non-resident
\npath is left alone: ntfs_lookup() already holds the directory inode’s
\nmrec_lock when it reads an index folio through read_mapping_folio(), and
\ntaking the lock in the shared wrapper deadlocks there with recursive locking
\non mrec_lock. The comment above the read_mapping_folio() call in
\nfs\/ntfs\/dir.c notes the same hazard.<\/p>\n
The seek path uses the same lookup helper but does not dereference
\niomap->inline_data. Release the lock before returning from that path,
\nwhereas the regular read path records base_ni in iomap->private and releases
\nthe lock from its iomap_end() callback.<\/p>\n
Tested with a reproducer that faults in a 16-byte resident file while
\nanother thread runs link()\/unlink() on it. Before: 40 KCSAN reports in
\nabout one second. After: no reports in 180 seconds over 206,090 read
\niterations and 423,540 link\/unlink cycles. A PROVE_LOCKING build shows no
\nlockdep splat with the same reproducer running for 60 seconds.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ntfs: serialize resident iomap reads with mrec_lock<\/p>\n
ntfs_read_iomap_begin_resident() walks the MFT record through
\nntfs_attr_lookup<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-25540","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/25540","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}