<?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 02:39:26 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-89495</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-89495</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2026-89495</guid>
    </item>
    <item>
      <title>fkie_cve-2026-89495</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-89495</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ocfs2: bound namelen in dlm_migrate_request_handler&lt;/p&gt;
&lt;p&gt;Patch series &amp;#34;ocfs2/dlm: bound peer-controlled lengths in the o2dlm&amp;#34;.&lt;/p&gt;
&lt;p&gt;The o2dlm receive handlers trust u8 length and count fields from the wire
without bounding them, so a node in a DLM domain can corrupt or panic any
other node with a malformed message.  Three defects:&lt;/p&gt;
&lt;p&gt;- dlm_migrate_request_handler() passes migrate-&amp;gt;namelen unchecked to
    dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an
    o2dlm_mle slab object: a heap out-of-bounds write of up to ~215
    attacker-controlled bytes.&lt;/p&gt;
&lt;p&gt;- dlm_mig_lockres_handler() passes mres-&amp;gt;lockname_len unchecked to
    dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname
    slab object: a heap out-of-bounds write of up to ~223 bytes.&lt;/p&gt;
&lt;p&gt;- the same handler trusts mres-&amp;gt;num_locks without checking that the
    message is large enough to hold that many entries, so
    dlm_process_recovery_data() walks mres-&amp;gt;ml[] past the kmalloc(data_len)
    copy and trips a BUG_ON (an out-of-bounds read ending in a panic).&lt;/p&gt;
&lt;p&gt;The other o2dlm receive handlers already reject an oversized name; the
migration and recovery handlers have omitted it since the DLM was added
(see the Fixes tags).  Patch 1 bounds namelen; patch 2 validates
lockname_len, num_locks, and the payload size.  Conforming recovery and
migration traffic is unaffected.&lt;/p&gt;
&lt;p&gt;o2net authenticates peers only by the DLM domain key, so any no…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ocfs2: bound namelen in dlm_migrate_request_handler&lt;/p&gt;
&lt;p&gt;Patch series &amp;#34;ocfs2/dlm: bound peer-controlled lengths in the o2dlm&amp;#34;.&lt;/p&gt;
&lt;p&gt;The o2dlm receive handlers trust u8 length and count fields from the wire
without bounding them, so a node in a DLM domain can corrupt or panic any
other node with a malformed message.  Three defects:&lt;/p&gt;
&lt;p&gt;- dlm_migrate_request_handler() passes migrate-&amp;gt;namelen unchecked to
    dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an
    o2dlm_mle slab object: a heap out-of-bounds write of up to ~215
    attacker-controlled bytes.&lt;/p&gt;
&lt;p&gt;- dlm_mig_lockres_handler() passes mres-&amp;gt;lockname_len unchecked to
    dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname
    slab object: a heap out-of-bounds write of up to ~223 bytes.&lt;/p&gt;
&lt;p&gt;- the same handler trusts mres-&amp;gt;num_locks without checking that the
    message is large enough to hold that many entries, so
    dlm_process_recovery_data() walks mres-&amp;gt;ml[] past the kmalloc(data_len)
    copy and trips a BUG_ON (an out-of-bounds read ending in a panic).&lt;/p&gt;
&lt;p&gt;The other o2dlm receive handlers already reject an oversized name; the
migration and recovery handlers have omitted it since the DLM was added
(see the Fixes tags).  Patch 1 bounds namelen; patch 2 validates
lockname_len, num_locks, and the payload size.  Conforming recovery and
migration traffic is unaffected.&lt;/p&gt;
&lt;p&gt;o2net authenticates peers only by the DLM domain key, so any no…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-89495</guid>
    </item>
    <item>
      <title>GHSA-3pmg-pq3r-v8mc</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-3pmg-pq3r-v8mc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ocfs2: bound namelen in dlm_migrate_request_handler&lt;/p&gt;
&lt;p&gt;Patch series &amp;#34;ocfs2/dlm: bound peer-controlled lengths in the o2dlm&amp;#34;.&lt;/p&gt;
&lt;p&gt;The o2dlm receive handlers trust u8 length and count fields from the wire
without bounding them, so a node in a DLM domain can corrupt or panic any
other node with a malformed message.  Three defects:&lt;/p&gt;
&lt;p&gt;- dlm_migrate_request_handler() passes migrate-&amp;gt;namelen unchecked to
    dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an
    o2dlm_mle slab object: a heap out-of-bounds write of up to ~215
    attacker-controlled bytes.&lt;/p&gt;
&lt;p&gt;- dlm_mig_lockres_handler() passes mres-&amp;gt;lockname_len unchecked to
    dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname
    slab object: a heap out-of-bounds write of up to ~223 bytes.&lt;/p&gt;
&lt;p&gt;- the same handler trusts mres-&amp;gt;num_locks without checking that the
    message is large enough to hold that many entries, so
    dlm_process_recovery_data() walks mres-&amp;gt;ml[] past the kmalloc(data_len)
    copy and trips a BUG_ON (an out-of-bounds read ending in a panic).&lt;/p&gt;
&lt;p&gt;The other o2dlm receive handlers already reject an oversized name; the
migration and recovery handlers have omitted it since the DLM was added
(see the Fixes tags).  Patch 1 bounds namelen; patch 2 validates
lockname_len, num_locks, and the payload size.  Conforming recovery and
migration traffic is unaffected.&lt;/p&gt;
&lt;p&gt;o2net authenticates peers only by the DLM domain key, so any no…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ocfs2: bound namelen in dlm_migrate_request_handler&lt;/p&gt;
&lt;p&gt;Patch series &amp;#34;ocfs2/dlm: bound peer-controlled lengths in the o2dlm&amp;#34;.&lt;/p&gt;
&lt;p&gt;The o2dlm receive handlers trust u8 length and count fields from the wire
without bounding them, so a node in a DLM domain can corrupt or panic any
other node with a malformed message.  Three defects:&lt;/p&gt;
&lt;p&gt;- dlm_migrate_request_handler() passes migrate-&amp;gt;namelen unchecked to
    dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an
    o2dlm_mle slab object: a heap out-of-bounds write of up to ~215
    attacker-controlled bytes.&lt;/p&gt;
&lt;p&gt;- dlm_mig_lockres_handler() passes mres-&amp;gt;lockname_len unchecked to
    dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname
    slab object: a heap out-of-bounds write of up to ~223 bytes.&lt;/p&gt;
&lt;p&gt;- the same handler trusts mres-&amp;gt;num_locks without checking that the
    message is large enough to hold that many entries, so
    dlm_process_recovery_data() walks mres-&amp;gt;ml[] past the kmalloc(data_len)
    copy and trips a BUG_ON (an out-of-bounds read ending in a panic).&lt;/p&gt;
&lt;p&gt;The other o2dlm receive handlers already reject an oversized name; the
migration and recovery handlers have omitted it since the DLM was added
(see the Fixes tags).  Patch 1 bounds namelen; patch 2 validates
lockname_len, num_locks, and the payload size.  Conforming recovery and
migration traffic is unaffected.&lt;/p&gt;
&lt;p&gt;o2net authenticates peers only by the DLM domain key, so any no…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-3pmg-pq3r-v8mc</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-89495 — ocfs2: bound namelen in dlm_migrate_request_handler</title>
      <link>https://vulnerability.circl.lu/vuln/msrc_cve-2026-89495</link>
      <description>msrc_CVE-2026-89495</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/msrc_cve-2026-89495</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media</title>
      <link>https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-89495</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-89495</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ocfs2: bound namelen in dlm_migrate_request_handler Patch series &amp;#34;ocfs2/dlm: bound peer-controlled lengths in the o2dlm&amp;#34;. The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message.  Three defects:   - dlm_migrate_request_handler() passes migrate-&amp;gt;namelen unchecked to     dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an     o2dlm_mle slab object: a heap out-of-bounds write of up to ~215     attacker-controlled bytes.   - dlm_mig_lockres_handler() passes mres-&amp;gt;lockname_len unchecked to     dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname     slab object: a heap out-of-bounds write of up to ~223 bytes.   - the same handler trusts mres-&amp;gt;num_locks without checking that the     message is large enough to hold that many entries, so     dlm_process_recovery_data() walks mres-&amp;gt;ml[] past the kmalloc(data_len)     copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags).  Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size.  Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ocfs2: bound namelen in dlm_migrate_request_handler Patch series &amp;#34;ocfs2/dlm: bound peer-controlled lengths in the o2dlm&amp;#34;. The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message.  Three defects:   - dlm_migrate_request_handler() passes migrate-&amp;gt;namelen unchecked to     dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an     o2dlm_mle slab object: a heap out-of-bounds write of up to ~215     attacker-controlled bytes.   - dlm_mig_lockres_handler() passes mres-&amp;gt;lockname_len unchecked to     dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname     slab object: a heap out-of-bounds write of up to ~223 bytes.   - the same handler trusts mres-&amp;gt;num_locks without checking that the     message is large enough to hold that many entries, so     dlm_process_recovery_data() walks mres-&amp;gt;ml[] past the kmalloc(data_len)     copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags).  Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size.  Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-89495</guid>
    </item>
  </channel>
</rss>
