https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 02:41:14 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-89494 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-89494 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253 certfr-2026-avi-1253 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253 https://cve.radiocsirt.org/vuln/euvd-2026-367602 EUVD-2026-367602 https://cve.radiocsirt.org/vuln/euvd-2026-367602 https://cve.radiocsirt.org/vuln/fkie_cve-2026-89494 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ocfs2: validate lengths in dlm_mig_lockres_handler</p> <p>A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres-&gt;ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain.</p> <p>Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres-&gt;lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len &lt;= DLM_LOCKID_NAME_MAX, num_locks &lt;= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ocfs2: validate lengths in dlm_mig_lockres_handler</p> <p>A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres-&gt;ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain.</p> <p>Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres-&gt;lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len &lt;= DLM_LOCKID_NAME_MAX, num_locks &lt;= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-89494 https://cve.radiocsirt.org/vuln/ghsa-hhc4-rpwx-gp2p <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ocfs2: validate lengths in dlm_mig_lockres_handler</p> <p>A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres-&gt;ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain.</p> <p>Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres-&gt;lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len &lt;= DLM_LOCKID_NAME_MAX, num_locks &lt;= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ocfs2: validate lengths in dlm_mig_lockres_handler</p> <p>A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres-&gt;ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain.</p> <p>Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres-&gt;lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len &lt;= DLM_LOCKID_NAME_MAX, num_locks &lt;= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.</p> https://cve.radiocsirt.org/vuln/ghsa-hhc4-rpwx-gp2p https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1 <p>kernel-devel-7.2.7-1.1 on GA media</p> <p>kernel-devel-7.2.7-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-89494 <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: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres-&gt;ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres-&gt;lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len &lt;= DLM_LOCKID_NAME_MAX, num_locks &lt;= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.</p> <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: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres-&gt;ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres-&gt;lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len &lt;= DLM_LOCKID_NAME_MAX, num_locks &lt;= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-89494 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3321 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, Daten oder den Systemzustand zu manipulieren, Denial-of-Service-Zustände herbeizuführen oder andere, nicht näher spezifizierte Angriffe durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, Daten oder den Systemzustand zu manipulieren, Denial-of-Service-Zustände herbeizuführen oder andere, nicht näher spezifizierte Angriffe durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3321