Description
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.
Published: 2026-09-17
Score: 7.1 High
EPSS: < 1% Very Low
KEV: No
Impact: Data Corruption
Action: Patch Immediately
AI Analysis

Impact

The Linux kernel’s NTFS driver contains a race condition where reading resident inode map data occurs without holding the mrec_lock, while concurrent write operations such as ntfs_attr_record_resize can relocate the same MFT record under the lock. This allows a reader to observe torn attribute length and offset fields, as demonstrated by KCSAN reports during mmap fault handling versus link/unlink operations. As a result, a user process may read corrupted or incomplete file metadata, causing data integrity problems or application crashes. The vulnerability does not provide a direct execution vector, but it can lead to denial of service or brief corruption of NTFS file attributes.

Affected Systems

All Linux kernel versions that include the ntfs module are affected. Any system that mounts an NTFS filesystem—and thereby exposes the ntfs module to userspace—is potentially impacted. The flaw originates within the kernel driver and is independent of distribution or specific kernel release numbers.

Risk and Exploitability

The EPSS score is below 1 %, and the vulnerability is not listed in the CISA KEV catalog, indicating a low likelihood of mass exploitation. The CVSS score of 7.1 indicates moderate severity in the Common Vulnerability Scoring System. Based on the description, it is inferred that an attacker requires local privileges to simultaneously perform a read (via mmap or file access) and a link or unlink operation on a resident NTFS file. Triggering the race could lead to temporary data corruption or denial of service, but the flaw does not appear to allow arbitrary code execution or remote compromise.

Generated by OpenCVE AI on September 20, 2026 at 02:25 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply a kernel update that includes the change introduced by commit 0400e0d50…
  • Restart the system or reload the kernel modules so the updated code takes effect
  • Until the update is applied, avoid performing concurrent read and link/unlink operations on resident NTFS files

Generated by OpenCVE AI on September 20, 2026 at 02:25 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 20 Sep 2026 02:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Fri, 18 Sep 2026 21:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.1, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H'}


Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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.
Title ntfs: serialize resident iomap reads with mrec_lock
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-18T17:53:11.332Z

Reserved: 2026-09-11T19:38:34.788Z

Link: CVE-2026-90131

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:05.617

Modified: 2026-09-18T18:17:42.863

Link: CVE-2026-90131

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T02:30:17Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')