CVE-2026-90131 (GCVE-0-2026-90131)

Vulnerability from cvelistv5 – Published: 2026-09-17 16:06 – Updated: 2026-09-18 17:53
VLAI
Title
ntfs: serialize resident iomap reads with mrec_lock
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 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.
Severity
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: b041ca562526b3c4a71b41b80ba5e520eac636ad , < 0400e0d50eb3be19c98323faa322b652e4ae3f99 (git)
Affected: b041ca562526b3c4a71b41b80ba5e520eac636ad , < d9e00c457d4ab8ab59c6e4b8554c921260e4e16c (git)
guessed Create a notification for this product.
Linux Linux Affected: 7.1
Unaffected: 0 , < 7.1 (semver)
Unaffected: 7.2.6 , ≤ 7.2.* (semver)
Unaffected: 7.3-rc1 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/ntfs/iomap.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "0400e0d50eb3be19c98323faa322b652e4ae3f99",
              "status": "affected",
              "version": "b041ca562526b3c4a71b41b80ba5e520eac636ad",
              "versionType": "git"
            },
            {
              "lessThan": "d9e00c457d4ab8ab59c6e4b8554c921260e4e16c",
              "status": "affected",
              "version": "b041ca562526b3c4a71b41b80ba5e520eac636ad",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/ntfs/iomap.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "7.1"
            },
            {
              "lessThan": "7.1",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.6",
                  "versionStartIncluding": "7.1",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc1",
                  "versionStartIncluding": "7.1",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: serialize resident iomap reads with mrec_lock\n\nntfs_read_iomap_begin_resident() walks the MFT record through\nntfs_attr_lookup() -\u003e ntfs_attr_find() without taking ni-\u003emrec_lock,\nwhile ntfs_attr_record_resize(), ntfs_make_room_for_attr() and\nntfs_resident_attr_record_add() memmove() the same base_ni-\u003emrec 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.\n\nKCSAN reports the race between the mmap read fault path and both link()\nand unlink():\n\n  BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize\n\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\n\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\n\n  value changed: 0x00000250 -\u003e 0x000001f0\n\nThe 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.\n\nKeep base_ni-\u003emrec_lock from the resident read iomap lookup through\niomap_end(). This protects both the attribute walk and the subsequent copy\nfrom iomap-\u003einline_data, which points into the MFT record. The non-resident\npath is left alone: ntfs_lookup() already holds the directory inode\u0027s\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.\n\nThe seek path uses the same lookup helper but does not dereference\niomap-\u003einline_data. Release the lock before returning from that path,\nwhereas the regular read path records base_ni in iomap-\u003eprivate and releases\nthe lock from its iomap_end() callback.\n\nTested 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The raced bytes are the in-memory MFT record (ni-\u003emrec) copied from disk by map_mft_record_folio, not a protocol payload. One thread hits filemap_fault -\u003e ntfs_read_folio -\u003e ntfs_read_iomap_begin_resident -\u003e ntfs_attr_find; the other is local linkat/unlinkat via vfs_link/vfs_unlink -\u003e ntfs_link/ntfs_unlink -\u003e ntfs_attr_record_resize memmove of that same buffer.\nAC:L - The attacker drives both sides: mmap of a resident file so filemap_fault takes ntfs_read_iomap_begin_resident without i_rwsem, while another thread link()/unlink()s so ntfs_attr_record_rm or ntfs_make_room_for_attr memmoves the mrec under mrec_lock. The commit reproducer got 40 KCSAN hits per second on that pair.\nPR:L - ntfs_file_open has no capability check. On an already-mounted writable NTFS volume, an unprivileged user who can mmap a small resident $DATA file and create/remove hard links in a writable directory reaches both the fault path and vfs_link/vfs_unlink. ntfs_fs_type is FS_REQUIRES_DEV without FS_USERNS_MOUNT, so mounting itself needs CAP_SYS_ADMIN but is not required here.\nUI:N - The attacker mmap-faults their own resident file while their other thread runs link()/unlink() on it, matching the commit\u0027s 16-byte-file reproducer. No victim mount or crafted image is required; a normal NTFS volume with a small file is enough.\nS:U - The race is inside fs/ntfs on that inode\u0027s kmalloc\u0027d mrec and the faulting file\u0027s page-cache folio. It does not cross a KVM, IOMMU, or sandbox boundary.\nC:H - ntfs_read_iomap_begin_resident sets iomap-\u003einline_data to ctx-\u003eattr plus resident.value_offset with no mrec-size check. ntfs_attr_find computes space from bytes_in_use (KCSAN: 0x250-\u003e0x1f0); unsigned underflow plus a torn a-\u003elength lets ntfs_resident_attr_value_get accept a value_offset past the kmalloc mft_record_size buffer, and iomap_read_inline_data folio_fill_tail()s that into a folio the attacker reads.\nI:N - The racy path only reads ni-\u003emrec and copies into the mmapped file\u0027s folio via iomap_read_inline_data. ntfs_attr_record_resize\u0027s memmove is the legitimate link/unlink writer holding mrec_lock and does not give the attacker an arbitrary kernel write.\nA:H - iomap_read_inline_data copies from a value_offset that can lie tens of kilobytes past the kmalloc\u0027d mrec into unmapped heap, oopsing on the filemap_fault path and taking the kernel down."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-18T17:53:11.332Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/0400e0d50eb3be19c98323faa322b652e4ae3f99"
        },
        {
          "url": "https://git.kernel.org/stable/c/d9e00c457d4ab8ab59c6e4b8554c921260e4e16c"
        }
      ],
      "title": "ntfs: serialize resident iomap reads with mrec_lock",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-90131",
    "datePublished": "2026-09-17T16:06:31.913Z",
    "dateReserved": "2026-09-11T19:38:34.788Z",
    "dateUpdated": "2026-09-18T17:53:11.332Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-90131",
      "date": "2026-09-25",
      "epss": "0.00156",
      "percentile": "0.04044"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "fs/ntfs/iomap.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "0400e0d50eb3be19c98323faa322b652e4ae3f99",
                    "status": "affected",
                    "version": "b041ca562526b3c4a71b41b80ba5e520eac636ad",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "d9e00c457d4ab8ab59c6e4b8554c921260e4e16c",
                    "status": "affected",
                    "version": "b041ca562526b3c4a71b41b80ba5e520eac636ad",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "fs/ntfs/iomap.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "7.1"
                  },
                  {
                    "lessThan": "7.1",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.2.*",
                    "status": "unaffected",
                    "version": "7.2.6",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.3-rc1",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: serialize resident iomap reads with mrec_lock\n\nntfs_read_iomap_begin_resident() walks the MFT record through\nntfs_attr_lookup() -\u003e ntfs_attr_find() without taking ni-\u003emrec_lock,\nwhile ntfs_attr_record_resize(), ntfs_make_room_for_attr() and\nntfs_resident_attr_record_add() memmove() the same base_ni-\u003emrec 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.\n\nKCSAN reports the race between the mmap read fault path and both link()\nand unlink():\n\n  BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize\n\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\n\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\n\n  value changed: 0x00000250 -\u003e 0x000001f0\n\nThe 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.\n\nKeep base_ni-\u003emrec_lock from the resident read iomap lookup through\niomap_end(). This protects both the attribute walk and the subsequent copy\nfrom iomap-\u003einline_data, which points into the MFT record. The non-resident\npath is left alone: ntfs_lookup() already holds the directory inode\u0027s\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.\n\nThe seek path uses the same lookup helper but does not dereference\niomap-\u003einline_data. Release the lock before returning from that path,\nwhereas the regular read path records base_ni in iomap-\u003eprivate and releases\nthe lock from its iomap_end() callback.\n\nTested 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."
          }
        ],
        "id": "CVE-2026-90131",
        "lastModified": "2026-09-18T18:17:42.863",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.1,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.2,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-09-17T17:17:05.617",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/0400e0d50eb3be19c98323faa322b652e4ae3f99"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/d9e00c457d4ab8ab59c6e4b8554c921260e4e16c"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.