---
id: CVE-2026-90131
title: |-
  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…
summary: |-
  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…
severity: high
cvss: 7.1
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H'
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= b041ca562526b3c4a71b41b80ba5e520eac636ad <
    0400e0d50eb3be19c98323faa322b652e4ae3f99
  - >-
    Linux >= b041ca562526b3c4a71b41b80ba5e520eac636ad <
    d9e00c457d4ab8ab59c6e4b8554c921260e4e16c
  - Linux 7.1
published: '2026-09-17'
updated: '2026-09-18'
sourceUpdated: '2026-09-18T18:17:42.863'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-90131'
references:
  - url: 'https://git.kernel.org/stable/c/0400e0d50eb3be19c98323faa322b652e4ae3f99'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/d9e00c457d4ab8ab59c6e4b8554c921260e4e16c'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
epss: 0.00156
epssPercentile: 0.04018
ingestedAt: '2026-09-17T16:21:47.880Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.