<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T16:07:48.802201+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/bell-cve-2026-72203</id>
    <title>BELL-CVE-2026-72203</title>
    <updated>2026-10-03T16:07:48.905052+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-72203"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-355303</id>
    <title>EUVD-2026-355303</title>
    <updated>2026-10-03T16:07:48.905104+00:00</updated>
    <content>EUVD-2026-355303</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-355303"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-72203</id>
    <title>fkie_cve-2026-72203</title>
    <updated>2026-10-03T16:07:48.905120+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: skip extent mft records in writeback to prevent deadlock</p>
<p>This patch fixes the ABBA deadlock between extent_lock and extent
mrec_lock triggered by xfstests generic/113, that occurs since the commit
6994acf33bae ("ntfs: use base mft_no when looking up base inode for
		extent record").</p>
<p>Path A (inode writeback):
  VFS writeback
    -&gt; ntfs_write_inode()
      -&gt; __ntfs_write_inode()
        -&gt; mutex_lock(&amp;ni-&gt;extent_lock)
        -&gt; mutex_lock(&amp;tni-&gt;mrec_lock)</p>
<p>Path B (MFT folio writeback):
  VFS writeback of $MFT dirty folios
    -&gt; ntfs_mft_writepages()
      -&gt; ntfs_write_mft_block()
        -&gt; ntfs_may_write_mft_record()
          -&gt; holds one extent mrec_lock from a previous iteration
          -&gt; tries to acquire another base inode extent_lock</p>
<p>By removing all extent_lock and extent mrec_lock acquisition from the MFT
folio writeback path, the ABBA lock ordering is eliminated:</p>
<p>Path A: __ntfs_write_inode(): extent_lock -&gt; mrec_lock
Path B (removed): ntfs_write_mft_block(): mrec_lock -&gt; extent_lock</p>
<p>Path B is always redundant for extent records because:</p>
<p>1. mark_mft_record_dirty(ext_ni) does NOT dirty the MFT folio.
   It only sets NInoDirty(ext_ni) and marks the base VFS inode dirty
   via __mark_inode_dirty(I_DIRTY_DATASYNC), which triggers Path A.
   Therefore, normal extent modifications never create a situation where
   the MFT folio is dirty and Path B is not scheduled.</p>
<p>2. The MFT folio only…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-72203"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-p3pr-3qq8-w67c</id>
    <title>GHSA-p3pr-3qq8-w67c</title>
    <updated>2026-10-03T16:07:48.905213+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: skip extent mft records in writeback to prevent deadlock</p>
<p>This patch fixes the ABBA deadlock between extent_lock and extent
mrec_lock triggered by xfstests generic/113, that occurs since the commit
6994acf33bae ("ntfs: use base mft_no when looking up base inode for
		extent record").</p>
<p>Path A (inode writeback):
  VFS writeback
    -&gt; ntfs_write_inode()
      -&gt; __ntfs_write_inode()
        -&gt; mutex_lock(&amp;ni-&gt;extent_lock)
        -&gt; mutex_lock(&amp;tni-&gt;mrec_lock)</p>
<p>Path B (MFT folio writeback):
  VFS writeback of $MFT dirty folios
    -&gt; ntfs_mft_writepages()
      -&gt; ntfs_write_mft_block()
        -&gt; ntfs_may_write_mft_record()
          -&gt; holds one extent mrec_lock from a previous iteration
          -&gt; tries to acquire another base inode extent_lock</p>
<p>By removing all extent_lock and extent mrec_lock acquisition from the MFT
folio writeback path, the ABBA lock ordering is eliminated:</p>
<p>Path A: __ntfs_write_inode(): extent_lock -&gt; mrec_lock
Path B (removed): ntfs_write_mft_block(): mrec_lock -&gt; extent_lock</p>
<p>Path B is always redundant for extent records because:</p>
<p>1. mark_mft_record_dirty(ext_ni) does NOT dirty the MFT folio.
   It only sets NInoDirty(ext_ni) and marks the base VFS inode dirty
   via __mark_inode_dirty(I_DIRTY_DATASYNC), which triggers Path A.
   Therefore, normal extent modifications never create a situation where
   the MFT folio is dirty and Path B is not scheduled.</p>
<p>2. The MFT folio only…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-p3pr-3qq8-w67c"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2026-72203</id>
    <title>msrc_CVE-2026-72203 — ntfs: skip extent mft records in writeback to prevent deadlock</title>
    <updated>2026-10-03T16:07:48.905252+00:00</updated>
    <content>msrc_CVE-2026-72203</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2026-72203"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72203</id>
    <title>UBUNTU-CVE-2026-72203</title>
    <updated>2026-10-03T16:07:48.905269+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: ntfs: skip extent mft records in writeback to prevent deadlock This patch fixes the ABBA deadlock between extent_lock and extent mrec_lock triggered by xfstests generic/113, that occurs since the commit 6994acf33bae ("ntfs: use base mft_no when looking up base inode for 		extent record"). Path A (inode writeback):   VFS writeback     -&gt; ntfs_write_inode()       -&gt; __ntfs_write_inode()         -&gt; mutex_lock(&amp;ni-&gt;extent_lock)         -&gt; mutex_lock(&amp;tni-&gt;mrec_lock) Path B (MFT folio writeback):   VFS writeback of $MFT dirty folios     -&gt; ntfs_mft_writepages()       -&gt; ntfs_write_mft_block()         -&gt; ntfs_may_write_mft_record()           -&gt; holds one extent mrec_lock from a previous iteration           -&gt; tries to acquire another base inode extent_lock By removing all extent_lock and extent mrec_lock acquisition from the MFT folio writeback path, the ABBA lock ordering is eliminated: Path A: __ntfs_write_inode(): extent_lock -&gt; mrec_lock Path B (removed): ntfs_write_mft_block(): mrec_lock -&gt; extent_lock Path B is always redundant for extent records because: 1. mark_mft_record_dirty(ext_ni) does NOT dirty the MFT folio.    It only sets NInoDirty(ext_ni) and marks the base VFS inode dirty    via __mark_inode_dirty(I_DIRTY_DATASYNC), which triggers Path A.    Therefore, normal extent modifications never create a situation where    the MFT folio is dirty and Path B is not scheduled. 2. The MFT folio only gets dirt…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72203"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</id>
    <title>WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-03T16:07:48.905613+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852"/>
  </entry>
</feed>
