{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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() -\u003e ntfs_attr_find() without taking ni-\u003emrec_lock, while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and ntfs_resident_attr_record_add() memmove() the same base_ni-\u003emrec 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 -\u003e 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-\u003emrec_lock from the resident read iomap lookup through iomap_end(). This protects both the attribute walk and the subsequent copy from iomap-\u003einline_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-\u003einline_data. Release the lock before returning from that path, whereas the regular read path records base_ni in iomap-\u003eprivate 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.",
  "id": "DEBIAN-CVE-2026-90131",
  "modified": "2026-09-19T22:47:35.259975031Z",
  "published": "2026-09-17T17:17:05.617Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-90131"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-90131"
  ]
}