Linux Kernel up to 7.2.5 NTFS fs/ntfs/dir.c ntfs_read_iomap_begin_resident race condition

CVSS Meta Temp Score
CVSS is a standardized scoring system to determine possibilities of attacks. The Temp Score considers temporal factors like disclosure, exploit and countermeasures. The unique Meta Score calculates the average score of different sources to provide a normalized scoring system.
Current Exploit Price (≈)
Our analysts are monitoring exploit markets and are in contact with vulnerability brokers. The range indicates the observed or calculated exploit price to be seen on exploit markets. A good indicator to understand the monetary effort required for and the popularity of an attack.
CTI Interest Score
Our Cyber Threat Intelligence team is monitoring different web sites, mailing lists, exploit markets and social media networks. The CTI Interest Score identifies the interest of attackers and the security community for this specific vulnerability in real-time. A high score indicates an elevated risk to be targeted for this vulnerability.
8.4$0-$5k0.00-

Summaryinfo

A vulnerability marked as very critical has been reported in Linux Kernel up to 7.2.5. The impacted element is the function ntfs_read_iomap_begin_resident of the file fs/ntfs/dir.c of the component NTFS. The manipulation leads to race condition. This vulnerability is referenced as CVE-2026-90131. The attack can only be performed from a local environment. No exploit is available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 7.2.5. It has been rated as very critical. This issue affects the function ntfs_read_iomap_begin_resident of the file fs/ntfs/dir.c of the component NTFS. The manipulation with an unknown input leads to a race condition vulnerability. Using CWE to declare the problem leads to CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

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.

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-90131 since 09/11/2026. The exploitation is known to be easy. Attacking locally is a requirement. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 09/18/2026).

The vulnerability scanner Nessus provides a plugin with the ID 347692 (Linux Distros Unpatched Vulnerability : CVE-2026-90131), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 7.2.6 or 7.3-rc1 eliminates this vulnerability. Applying the patch 0400e0d50eb3be19c98323faa322b652e4ae3f99/d9e00c457d4ab8ab59c6e4b8554c921260e4e16c is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at Tenable (347692). Be aware that VulDB is the high quality source for vulnerability data.

Productinfo

Type

Vendor

Name

Version

License

Website

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv3info

VulDB Meta Base Score: 8.8
VulDB Meta Temp Score: 8.4

VulDB Base Score: 8.8
VulDB Temp Score: 8.4
VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplexityAuthenticationConfidentialityIntegrityAvailability
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍

Exploitinginfo

Class: Race condition
CWE: CWE-362
CAPEC: 🔒
ATT&CK: 🔒

Physical: Partially
Local: Yes
Remote: No

Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒

0-DayUnlockUnlockUnlockUnlock
TodayUnlockUnlockUnlockUnlock

Nessus ID: 347692
Nessus Name: Linux Distros Unpatched Vulnerability : CVE-2026-90131

Threat Intelligenceinfo

Interest: 🔍
Active Actors: 🔍
Active APT Groups: 🔍

Countermeasuresinfo

Recommended: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 7.2.6/7.3-rc1
Patch: 0400e0d50eb3be19c98323faa322b652e4ae3f99/d9e00c457d4ab8ab59c6e4b8554c921260e4e16c

Timelineinfo

09/11/2026 CVE reserved
09/17/2026 +6 days Advisory disclosed
09/17/2026 +0 days VulDB entry created
09/18/2026 +1 days VulDB entry last update

Sourcesinfo

Vendor: kernel.org

Advisory: git.kernel.org
Status: Confirmed

CVE: CVE-2026-90131 (🔒)
GCVE (CVE): GCVE-0-2026-90131
GCVE (VulDB): GCVE-100-406655

Entryinfo

Created: 09/17/2026 19:54
Updated: 09/18/2026 12:54
Changes: 09/17/2026 19:54 (60), 09/18/2026 12:54 (2)
Complete: 🔍
Cache ID: 216::103

Be aware that VulDB is the high quality source for vulnerability data.

Discussion

No comments yet. Languages: en.

Please log in to comment.

◂ PreviousOverviewNext ▸

Want to know what is going to be exploited?

We predict KEV entries!