<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 22:16:08 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-90131 — ntfs: serialize resident iomap reads with mrec_lock</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-90131</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ntfs: serialize resident iomap reads with mrec_lock&lt;/p&gt;
&lt;p&gt;ntfs_read_iomap_begin_resident() walks the MFT record through
ntfs_attr_lookup() -&amp;gt; ntfs_attr_find() without taking ni-&amp;gt;mrec_lock,
while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and
ntfs_resident_attr_record_add() memmove() the same base_ni-&amp;gt;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.&lt;/p&gt;
&lt;p&gt;KCSAN reports the race between the mmap read fault path and both link()
and unlink():&lt;/p&gt;
&lt;p&gt;BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;value changed: 0x00000250 -&amp;gt; 0x000001f0&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Keep base_ni-&amp;gt;mre…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ntfs: serialize resident iomap reads with mrec_lock&lt;/p&gt;
&lt;p&gt;ntfs_read_iomap_begin_resident() walks the MFT record through
ntfs_attr_lookup() -&amp;gt; ntfs_attr_find() without taking ni-&amp;gt;mrec_lock,
while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and
ntfs_resident_attr_record_add() memmove() the same base_ni-&amp;gt;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.&lt;/p&gt;
&lt;p&gt;KCSAN reports the race between the mmap read fault path and both link()
and unlink():&lt;/p&gt;
&lt;p&gt;BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;value changed: 0x00000250 -&amp;gt; 0x000001f0&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Keep base_ni-&amp;gt;mre…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-90131</guid>
    </item>
  </channel>
</rss>
