<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T01:39:40.365892+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/bell-cve-2026-90131</id>
    <title>Withdrawn: BELL-CVE-2026-90131 — CVE-2026-90131 does not affect BellSoft software</title>
    <updated>2026-10-02T01:39:40.418890+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>
          <strong>Withdrawn by the publisher.</strong>
        </p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/bell-cve-2026-90131"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-90131</id>
    <title>fkie_cve-2026-90131</title>
    <updated>2026-10-02T01:39:40.418964+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>ntfs: serialize resident iomap reads with mrec_lock</p>
<p>ntfs_read_iomap_begin_resident() walks the MFT record through
ntfs_attr_lookup() -&gt; ntfs_attr_find() without taking ni-&gt;mrec_lock,
while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and
ntfs_resident_attr_record_add() memmove() the same base_ni-&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.</p>
<p>KCSAN reports the race between the mmap read fault path and both link()
and unlink():</p>
<p>BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize</p>
<p>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</p>
<p>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</p>
<p>value changed: 0x00000250 -&gt; 0x000001f0</p>
<p>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.</p>
<p>Keep base_ni-&gt;mre…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-90131"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-p65r-ghh2-3f2q</id>
    <title>GHSA-p65r-ghh2-3f2q</title>
    <updated>2026-10-02T01:39:40.419073+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>ntfs: serialize resident iomap reads with mrec_lock</p>
<p>ntfs_read_iomap_begin_resident() walks the MFT record through
ntfs_attr_lookup() -&gt; ntfs_attr_find() without taking ni-&gt;mrec_lock,
while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and
ntfs_resident_attr_record_add() memmove() the same base_ni-&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.</p>
<p>KCSAN reports the race between the mmap read fault path and both link()
and unlink():</p>
<p>BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize</p>
<p>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</p>
<p>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</p>
<p>value changed: 0x00000250 -&gt; 0x000001f0</p>
<p>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.</p>
<p>Keep base_ni-&gt;mre…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-p65r-ghh2-3f2q"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1</id>
    <title>openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media</title>
    <updated>2026-10-02T01:39:40.419149+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel-devel-7.2.7-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-90131</id>
    <title>UBUNTU-CVE-2026-90131</title>
    <updated>2026-10-02T01:39:40.419666+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 96 more</p>
<p>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() -&gt; ntfs_attr_find() without taking ni-&gt;mrec_lock, while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and ntfs_resident_attr_record_add() memmove() the same base_ni-&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. 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 -&gt; 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-&gt;mrec_lock fr…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-90131"/>
  </entry>
</feed>
