<?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://cve.radiocsirt.org</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>Sun, 04 Oct 2026 16:30:20 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-12481</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-12481</link>
      <description>bdu:2025-12481</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-12481</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-26837</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-26837</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://cve.radiocsirt.org/vuln/bell-cve-2024-26837</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0668 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Red Hat. Certaines d'entre elles permettent à un…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0668</link>
      <description>certfr-2024-avi-0668</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0668</guid>
    </item>
    <item>
      <title>EUVD-2026-312621</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-312621</link>
      <description>EUVD-2026-312621</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-312621</guid>
    </item>
    <item>
      <title>fkie_cve-2024-26837</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-26837</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: bridge: switchdev: Skip MDB replays of deferred events on offload&lt;/p&gt;
&lt;p&gt;Before this change, generation of the list of MDB events to replay
would race against the creation of new group memberships, either from
the IGMP/MLD snooping logic or from user configuration.&lt;/p&gt;
&lt;p&gt;While new memberships are immediately visible to walkers of
br-&amp;gt;mdb_list, the notification of their existence to switchdev event
subscribers is deferred until a later point in time. So if a replay
list was generated during a time that overlapped with such a window,
it would also contain a replay of the not-yet-delivered event.&lt;/p&gt;
&lt;p&gt;The driver would thus receive two copies of what the bridge internally
considered to be one single event. On destruction of the bridge, only
a single membership deletion event was therefore sent. As a
consequence of this, drivers which reference count memberships (at
least DSA), would be left with orphan groups in their hardware
database when the bridge was destroyed.&lt;/p&gt;
&lt;p&gt;This is only an issue when replaying additions. While deletion events
may still be pending on the deferred queue, they will already have
been removed from br-&amp;gt;mdb_list, so no duplicates can be generated in
that scenario.&lt;/p&gt;
&lt;p&gt;To a user this meant that old group memberships, from a bridge in
which a port was previously attached, could be reanimated (in
hardware) when the port joined a new bridge, without the new bridge&amp;#39;s
knowledge.&lt;/p&gt;
&lt;p&gt;For example, on an mv88e6xxx s…&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;net: bridge: switchdev: Skip MDB replays of deferred events on offload&lt;/p&gt;
&lt;p&gt;Before this change, generation of the list of MDB events to replay
would race against the creation of new group memberships, either from
the IGMP/MLD snooping logic or from user configuration.&lt;/p&gt;
&lt;p&gt;While new memberships are immediately visible to walkers of
br-&amp;gt;mdb_list, the notification of their existence to switchdev event
subscribers is deferred until a later point in time. So if a replay
list was generated during a time that overlapped with such a window,
it would also contain a replay of the not-yet-delivered event.&lt;/p&gt;
&lt;p&gt;The driver would thus receive two copies of what the bridge internally
considered to be one single event. On destruction of the bridge, only
a single membership deletion event was therefore sent. As a
consequence of this, drivers which reference count memberships (at
least DSA), would be left with orphan groups in their hardware
database when the bridge was destroyed.&lt;/p&gt;
&lt;p&gt;This is only an issue when replaying additions. While deletion events
may still be pending on the deferred queue, they will already have
been removed from br-&amp;gt;mdb_list, so no duplicates can be generated in
that scenario.&lt;/p&gt;
&lt;p&gt;To a user this meant that old group memberships, from a bridge in
which a port was previously attached, could be reanimated (in
hardware) when the port joined a new bridge, without the new bridge&amp;#39;s
knowledge.&lt;/p&gt;
&lt;p&gt;For example, on an mv88e6xxx s…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-26837</guid>
    </item>
    <item>
      <title>GHSA-8ppx-vmhm-cxj7</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8ppx-vmhm-cxj7</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: bridge: switchdev: Skip MDB replays of deferred events on offload&lt;/p&gt;
&lt;p&gt;Before this change, generation of the list of MDB events to replay
would race against the creation of new group memberships, either from
the IGMP/MLD snooping logic or from user configuration.&lt;/p&gt;
&lt;p&gt;While new memberships are immediately visible to walkers of
br-&amp;gt;mdb_list, the notification of their existence to switchdev event
subscribers is deferred until a later point in time. So if a replay
list was generated during a time that overlapped with such a window,
it would also contain a replay of the not-yet-delivered event.&lt;/p&gt;
&lt;p&gt;The driver would thus receive two copies of what the bridge internally
considered to be one single event. On destruction of the bridge, only
a single membership deletion event was therefore sent. As a
consequence of this, drivers which reference count memberships (at
least DSA), would be left with orphan groups in their hardware
database when the bridge was destroyed.&lt;/p&gt;
&lt;p&gt;This is only an issue when replaying additions. While deletion events
may still be pending on the deferred queue, they will already have
been removed from br-&amp;gt;mdb_list, so no duplicates can be generated in
that scenario.&lt;/p&gt;
&lt;p&gt;To a user this meant that old group memberships, from a bridge in
which a port was previously attached, could be reanimated (in
hardware) when the port joined a new bridge, without the new bridge&amp;#39;s
knowledge.&lt;/p&gt;
&lt;p&gt;For example, on an mv88e6xxx s…&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;net: bridge: switchdev: Skip MDB replays of deferred events on offload&lt;/p&gt;
&lt;p&gt;Before this change, generation of the list of MDB events to replay
would race against the creation of new group memberships, either from
the IGMP/MLD snooping logic or from user configuration.&lt;/p&gt;
&lt;p&gt;While new memberships are immediately visible to walkers of
br-&amp;gt;mdb_list, the notification of their existence to switchdev event
subscribers is deferred until a later point in time. So if a replay
list was generated during a time that overlapped with such a window,
it would also contain a replay of the not-yet-delivered event.&lt;/p&gt;
&lt;p&gt;The driver would thus receive two copies of what the bridge internally
considered to be one single event. On destruction of the bridge, only
a single membership deletion event was therefore sent. As a
consequence of this, drivers which reference count memberships (at
least DSA), would be left with orphan groups in their hardware
database when the bridge was destroyed.&lt;/p&gt;
&lt;p&gt;This is only an issue when replaying additions. While deletion events
may still be pending on the deferred queue, they will already have
been removed from br-&amp;gt;mdb_list, so no duplicates can be generated in
that scenario.&lt;/p&gt;
&lt;p&gt;To a user this meant that old group memberships, from a bridge in
which a port was previously attached, could be reanimated (in
hardware) when the port joined a new bridge, without the new bridge&amp;#39;s
knowledge.&lt;/p&gt;
&lt;p&gt;For example, on an mv88e6xxx s…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8ppx-vmhm-cxj7</guid>
    </item>
    <item>
      <title>gsd-2024-26837</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2024-26837</link>
      <description>gsd-2024-26837</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2024-26837</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-26837 — net: bridge: switchdev: Skip MDB replays of deferred events on offload</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-26837</link>
      <description>msrc_CVE-2024-26837</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-26837</guid>
    </item>
    <item>
      <title>RHSA-2024:5101 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:5101</link>
      <description>&lt;p&gt;kernel: tracing: Restructure trace_clock_global() to never block kernel: ensure definition of the fixmap area is in a limit kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: cifs: Fix memory leak when build ntlmssp negotiate blob failed kernel: x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() kernel: Local information disclosure on Intel(R) Atom(R) processors kernel: powerpc: Fix access beyond end of drmem array kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null po…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: tracing: Restructure trace_clock_global() to never block kernel: ensure definition of the fixmap area is in a limit kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: cifs: Fix memory leak when build ntlmssp negotiate blob failed kernel: x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() kernel: Local information disclosure on Intel(R) Atom(R) processors kernel: powerpc: Fix access beyond end of drmem array kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null po…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:5101</guid>
    </item>
    <item>
      <title>RHSA-2024:5102 — Red Hat Security Advisory: kernel-rt security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:5102</link>
      <description>&lt;p&gt;kernel: tracing: Restructure trace_clock_global() to never block kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null pointer dereference issues in ice_ptp.c kernel: drm: Don&amp;#39;t unref the same fb many times by mistake due to deadlock handling kernel: wifi: mac80211: fix potential key use-after-free kernel: pstore/ram: Fix crash when setting number of cpus to an odd number kernel: ext4: avoid online resizing failures due to oversiz…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: tracing: Restructure trace_clock_global() to never block kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null pointer dereference issues in ice_ptp.c kernel: drm: Don&amp;#39;t unref the same fb many times by mistake due to deadlock handling kernel: wifi: mac80211: fix potential key use-after-free kernel: pstore/ram: Fix crash when setting number of cpus to an odd number kernel: ext4: avoid online resizing failures due to oversiz…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:5102</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:3194-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:3194-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:3194-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-26837</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26837</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 105 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br-&amp;gt;mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br-&amp;gt;mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge&amp;#39;s knowledge. For example, on an mv88e6xxx system,…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 105 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br-&amp;gt;mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br-&amp;gt;mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge&amp;#39;s knowledge. For example, on an mv88e6xxx system,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26837</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0920 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0920</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0920</guid>
    </item>
  </channel>
</rss>
