The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-90131)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2026-90131

high Nessus Plugin ID 347692

Version 1.5