# CVE-2026-90131: linux: In the Linux kernel, the following vulnerability has been resolved:  ntfs: serialize resident iomap reads with mrec_l...

CVE-2026-90131 is fixed in linux on 1 platform by DEBIAN-CVE-2026-90131 (version 7.2.6-1), released September 23, 2026. It is not reported as exploited. Patch Radar priority: High.

- Web page: https://patchblox.com/security/cve/CVE-2026-90131
- Priority: High
- CVSS: 7.1 (high)
- EPSS: 0.0016
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Sep 17, 2026

## 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.

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 14 | 7.2.6-1 | [DEBIAN-CVE-2026-90131](https://patchblox.com/security/data/fix/linux/debian-cve-2026-90131.md) | Sep 23, 2026 |

---

Data as of 2026-11-08T19:12:23Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.