<?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>Sat, 03 Oct 2026 06:22:26 +0000</lastBuildDate>
    <item>
      <title>ALSA-2024:5928 — Important: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2024:5928</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 52 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: nftables: nft_set_rbtree skip end interval element from gc (CVE-2024-26581)
  * kernel: netfilter: nft_limit: reject configurations that cause integer overflow (CVE-2024-26668)
  * kernel: vfio/pci: Lock external INTx masking ops (CVE-2024-26810)
  * kernel: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() (CVE-2024-26855)
  * kernel: x86/xen: Add some null pointer checking to smp.c (CVE-2024-26908)
  * kernel: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path (CVE-2024-26925)
  * kernel: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() (CVE-2024-27020)
  * kernel: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() (CVE-2024-27019)
  * kernel: netfilter: flowtable: validate pppoe header (CVE-2024-27016)
  * kernel: netfilter: bridge: confirm multicast packets before passing them up the stack (CVE-2024-27415)
  * kernel: netfilter: bridge: replace physindev with physinif in nf_bridge_info (CVE-2024-35839)
  * kernel: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() (CVE-2024-35898)
  * kernel: netfilter: nf_tables: discard table flag update with pending basechain deletion (CVE-2024-35897)
  * kernel: netfilter: validate user input for expected length (CVE-2024-35896)
  * kernel: netfilter: complete validation of user input (CVE-2024-35962)
  *…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 52 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: nftables: nft_set_rbtree skip end interval element from gc (CVE-2024-26581)
  * kernel: netfilter: nft_limit: reject configurations that cause integer overflow (CVE-2024-26668)
  * kernel: vfio/pci: Lock external INTx masking ops (CVE-2024-26810)
  * kernel: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() (CVE-2024-26855)
  * kernel: x86/xen: Add some null pointer checking to smp.c (CVE-2024-26908)
  * kernel: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path (CVE-2024-26925)
  * kernel: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() (CVE-2024-27020)
  * kernel: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() (CVE-2024-27019)
  * kernel: netfilter: flowtable: validate pppoe header (CVE-2024-27016)
  * kernel: netfilter: bridge: confirm multicast packets before passing them up the stack (CVE-2024-27415)
  * kernel: netfilter: bridge: replace physindev with physinif in nf_bridge_info (CVE-2024-35839)
  * kernel: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() (CVE-2024-35898)
  * kernel: netfilter: nf_tables: discard table flag update with pending basechain deletion (CVE-2024-35897)
  * kernel: netfilter: validate user input for expected length (CVE-2024-35896)
  * kernel: netfilter: complete validation of user input (CVE-2024-35962)
  *…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/alsa-2024:5928</guid>
    </item>
    <item>
      <title>bdu:2025-13352</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-13352</link>
      <description>bdu:2025-13352</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-13352</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-35839</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-35839</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-35839</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0728 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Red Hat. Elles permettent à un attaquant de prov…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0728</link>
      <description>certfr-2024-avi-0728</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0728</guid>
    </item>
    <item>
      <title>EUVD-2026-345669</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345669</link>
      <description>EUVD-2026-345669</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345669</guid>
    </item>
    <item>
      <title>fkie_cve-2024-35839</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-35839</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: bridge: replace physindev with physinif in nf_bridge_info&lt;/p&gt;
&lt;p&gt;An skb can be added to a neigh-&amp;gt;arp_queue while waiting for an arp
reply. Where original skb&amp;#39;s skb-&amp;gt;dev can be different to neigh&amp;#39;s
neigh-&amp;gt;dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh-&amp;gt;arp_queue of the bridge.&lt;/p&gt;
&lt;p&gt;As skb-&amp;gt;dev can be reset back to nf_bridge-&amp;gt;physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn&amp;#39;t cleanup skbs from
different device&amp;#39;s neigh queue) we can crash on e.g. this stack:&lt;/p&gt;
&lt;p&gt;arp_process
  neigh_update
    skb = __skb_dequeue(&amp;amp;neigh-&amp;gt;arp_queue)
      neigh_resolve_output(..., skb)
        ...
          br_nf_dev_xmit
            br_nf_pre_routing_finish_bridge_slow
              skb-&amp;gt;dev = nf_bridge-&amp;gt;physindev
              br_handle_frame_finish&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don&amp;#39;t get it and drop skb.&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;netfilter: bridge: replace physindev with physinif in nf_bridge_info&lt;/p&gt;
&lt;p&gt;An skb can be added to a neigh-&amp;gt;arp_queue while waiting for an arp
reply. Where original skb&amp;#39;s skb-&amp;gt;dev can be different to neigh&amp;#39;s
neigh-&amp;gt;dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh-&amp;gt;arp_queue of the bridge.&lt;/p&gt;
&lt;p&gt;As skb-&amp;gt;dev can be reset back to nf_bridge-&amp;gt;physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn&amp;#39;t cleanup skbs from
different device&amp;#39;s neigh queue) we can crash on e.g. this stack:&lt;/p&gt;
&lt;p&gt;arp_process
  neigh_update
    skb = __skb_dequeue(&amp;amp;neigh-&amp;gt;arp_queue)
      neigh_resolve_output(..., skb)
        ...
          br_nf_dev_xmit
            br_nf_pre_routing_finish_bridge_slow
              skb-&amp;gt;dev = nf_bridge-&amp;gt;physindev
              br_handle_frame_finish&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don&amp;#39;t get it and drop skb.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-35839</guid>
    </item>
    <item>
      <title>GHSA-gw6v-2949-7c2m</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gw6v-2949-7c2m</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: bridge: replace physindev with physinif in nf_bridge_info&lt;/p&gt;
&lt;p&gt;An skb can be added to a neigh-&amp;gt;arp_queue while waiting for an arp
reply. Where original skb&amp;#39;s skb-&amp;gt;dev can be different to neigh&amp;#39;s
neigh-&amp;gt;dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh-&amp;gt;arp_queue of the bridge.&lt;/p&gt;
&lt;p&gt;As skb-&amp;gt;dev can be reset back to nf_bridge-&amp;gt;physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn&amp;#39;t cleanup skbs from
different device&amp;#39;s neigh queue) we can crash on e.g. this stack:&lt;/p&gt;
&lt;p&gt;arp_process
  neigh_update
    skb = __skb_dequeue(&amp;amp;neigh-&amp;gt;arp_queue)
      neigh_resolve_output(..., skb)
        ...
          br_nf_dev_xmit
            br_nf_pre_routing_finish_bridge_slow
              skb-&amp;gt;dev = nf_bridge-&amp;gt;physindev
              br_handle_frame_finish&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don&amp;#39;t get it and drop skb.&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;netfilter: bridge: replace physindev with physinif in nf_bridge_info&lt;/p&gt;
&lt;p&gt;An skb can be added to a neigh-&amp;gt;arp_queue while waiting for an arp
reply. Where original skb&amp;#39;s skb-&amp;gt;dev can be different to neigh&amp;#39;s
neigh-&amp;gt;dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh-&amp;gt;arp_queue of the bridge.&lt;/p&gt;
&lt;p&gt;As skb-&amp;gt;dev can be reset back to nf_bridge-&amp;gt;physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn&amp;#39;t cleanup skbs from
different device&amp;#39;s neigh queue) we can crash on e.g. this stack:&lt;/p&gt;
&lt;p&gt;arp_process
  neigh_update
    skb = __skb_dequeue(&amp;amp;neigh-&amp;gt;arp_queue)
      neigh_resolve_output(..., skb)
        ...
          br_nf_dev_xmit
            br_nf_pre_routing_finish_bridge_slow
              skb-&amp;gt;dev = nf_bridge-&amp;gt;physindev
              br_handle_frame_finish&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don&amp;#39;t get it and drop skb.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gw6v-2949-7c2m</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-35839 — netfilter: bridge: replace physindev with physinif in nf_bridge_info</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-35839</link>
      <description>msrc_CVE-2024-35839</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-35839</guid>
    </item>
    <item>
      <title>OESA-2024-1682 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1682</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume&#13;
&#13;
In current code, when a PCI error state pci_channel_io_normal is detectd,
it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI
driver will continue the execution of PCI resume callback report_resume by
pci_walk_bridge, and the callback will go into amdgpu_pci_resume
finally, where write lock is releasd unconditionally without acquiring
such lock first. In this case, a deadlock will happen when other threads
start to acquire the read lock.&#13;
&#13;
To fix this, add a member in amdgpu_device strucutre to cache
pci_channel_state, and only continue the execution in amdgpu_pci_resume
when it&amp;amp;apos;s pci_channel_io_frozen.(CVE-2021-47421)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
ptp: Fix possible memory leak in ptp_clock_register()&#13;
&#13;
I got memory leak as follows when doing fault injection test:&#13;
&#13;
unreferenced object 0xffff88800906c618 (size 8):
  comm &amp;amp;quot;i2c-idt82p33931&amp;amp;quot;, pid 4421, jiffies 4294948083 (age 13.188s)
  hex dump (first 8 bytes):
    70 74 70 30 00 00 00 00                          ptp0....
  backtrace:
    [&amp;amp;lt;00000000312ed458&amp;amp;gt;] __kmalloc_track_caller+0x19f/0x3a0
    [&amp;amp;lt;0000000079f6e2ff&amp;amp;gt;] kvasprintf+0xb5/0x150
    [&amp;amp;lt;0000000026aae54f&amp;amp;gt;] kvasprintf_const+0x60/0x190
    [&amp;amp;lt;000…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume&#13;
&#13;
In current code, when a PCI error state pci_channel_io_normal is detectd,
it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI
driver will continue the execution of PCI resume callback report_resume by
pci_walk_bridge, and the callback will go into amdgpu_pci_resume
finally, where write lock is releasd unconditionally without acquiring
such lock first. In this case, a deadlock will happen when other threads
start to acquire the read lock.&#13;
&#13;
To fix this, add a member in amdgpu_device strucutre to cache
pci_channel_state, and only continue the execution in amdgpu_pci_resume
when it&amp;amp;apos;s pci_channel_io_frozen.(CVE-2021-47421)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
ptp: Fix possible memory leak in ptp_clock_register()&#13;
&#13;
I got memory leak as follows when doing fault injection test:&#13;
&#13;
unreferenced object 0xffff88800906c618 (size 8):
  comm &amp;amp;quot;i2c-idt82p33931&amp;amp;quot;, pid 4421, jiffies 4294948083 (age 13.188s)
  hex dump (first 8 bytes):
    70 74 70 30 00 00 00 00                          ptp0....
  backtrace:
    [&amp;amp;lt;00000000312ed458&amp;amp;gt;] __kmalloc_track_caller+0x19f/0x3a0
    [&amp;amp;lt;0000000079f6e2ff&amp;amp;gt;] kvasprintf+0xb5/0x150
    [&amp;amp;lt;0000000026aae54f&amp;amp;gt;] kvasprintf_const+0x60/0x190
    [&amp;amp;lt;000…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1682</guid>
    </item>
    <item>
      <title>RHSA-2024:5928 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:5928</link>
      <description>&lt;p&gt;kernel: x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() kernel: cxl/port: Fix delete_endpoint() vs parent unregistration race kernel: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc kernel: nftables: nft_set_rbtree skip end interval element from gc kernel: netfilter: nft_limit: reject configurations that cause integer overflow kernel: vfio/pci: Lock external INTx masking ops kernel: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() kernel: x86/xen: Add some null pointer checking to smp.c kernel: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path kernel: netfilter: flowtable: validate pppoe header kernel: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() kernel: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() kernel: netfilter: bridge: confirm multicast packets before passing them up the stack kernel: netfilter: bridge: replace physindev with physinif in nf_bridge_info kernel: netfilter: validate user input for expected length kernel: netfilter: nf_tables: discard table flag update with pending basechain deletion kernel: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() kernel: netfilter: complete validation of user input kernel: ice: fix LAG and VF lock dependency in ice_reset_vf() kernel: scsi: qla2xxx: Fix off by one in qla_edif_app_getstats() kernel: net: bridge: xmit: make sure we have at least eth header len bytes kernel: bnxt_re: avoid shif…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() kernel: cxl/port: Fix delete_endpoint() vs parent unregistration race kernel: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc kernel: nftables: nft_set_rbtree skip end interval element from gc kernel: netfilter: nft_limit: reject configurations that cause integer overflow kernel: vfio/pci: Lock external INTx masking ops kernel: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() kernel: x86/xen: Add some null pointer checking to smp.c kernel: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path kernel: netfilter: flowtable: validate pppoe header kernel: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() kernel: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() kernel: netfilter: bridge: confirm multicast packets before passing them up the stack kernel: netfilter: bridge: replace physindev with physinif in nf_bridge_info kernel: netfilter: validate user input for expected length kernel: netfilter: nf_tables: discard table flag update with pending basechain deletion kernel: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() kernel: netfilter: complete validation of user input kernel: ice: fix LAG and VF lock dependency in ice_reset_vf() kernel: scsi: qla2xxx: Fix off by one in qla_edif_app_getstats() kernel: net: bridge: xmit: make sure we have at least eth header len bytes kernel: bnxt_re: avoid shif…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:5928</guid>
    </item>
    <item>
      <title>RHSA-2024:6267 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:6267</link>
      <description>&lt;p&gt;kernel: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address kernel: netfilter: bridge: replace physindev with physinif in nf_bridge_info kernel: x86/coco: Require seeding RNG with RDRAND on CoCo systems kernel: bpf, sockmap: Prevent lock inversion deadlock in map delete elem kernel: bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq kernel: gfs2: Fix potential glock use-after-free on unmount kernel: ionic: fix use after netif_napi_del() kernel: mm/huge_memory: don&amp;amp;#39;t unpoison huge_zero_folio kernel: dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list kernel: scsi: qedi: Fix crash while reading debugfs attribute kernel: tipc: force a dst refcount before doing decryption kernel: ppp: reject claimed-as-LCP but actually malformed packets kernel: Revert &amp;amp;#34;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again&amp;amp;#34; kernel: mm: avoid overflows in dirty throttling logic&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address kernel: netfilter: bridge: replace physindev with physinif in nf_bridge_info kernel: x86/coco: Require seeding RNG with RDRAND on CoCo systems kernel: bpf, sockmap: Prevent lock inversion deadlock in map delete elem kernel: bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq kernel: gfs2: Fix potential glock use-after-free on unmount kernel: ionic: fix use after netif_napi_del() kernel: mm/huge_memory: don&amp;amp;#39;t unpoison huge_zero_folio kernel: dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list kernel: scsi: qedi: Fix crash while reading debugfs attribute kernel: tipc: force a dst refcount before doing decryption kernel: ppp: reject claimed-as-LCP but actually malformed packets kernel: Revert &amp;amp;#34;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again&amp;amp;#34; kernel: mm: avoid overflows in dirty throttling logic&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:6267</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:0117-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:0117-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-2025:0117-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-35839</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35839</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 160 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: replace physindev with physinif in nf_bridge_info An skb can be added to a neigh-&amp;gt;arp_queue while waiting for an arp reply. Where original skb&amp;#39;s skb-&amp;gt;dev can be different to neigh&amp;#39;s neigh-&amp;gt;dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh-&amp;gt;arp_queue of the bridge. As skb-&amp;gt;dev can be reset back to nf_bridge-&amp;gt;physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn&amp;#39;t cleanup skbs from different device&amp;#39;s neigh queue) we can crash on e.g. this stack: arp_process   neigh_update     skb = __skb_dequeue(&amp;amp;neigh-&amp;gt;arp_queue)       neigh_resolve_output(..., skb)         ...           br_nf_dev_xmit             br_nf_pre_routing_finish_bridge_slow               skb-&amp;gt;dev = nf_bridge-&amp;gt;physindev               br_handle_frame_finish Let&amp;#39;s use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don&amp;#39;t get it and drop skb.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 160 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: replace physindev with physinif in nf_bridge_info An skb can be added to a neigh-&amp;gt;arp_queue while waiting for an arp reply. Where original skb&amp;#39;s skb-&amp;gt;dev can be different to neigh&amp;#39;s neigh-&amp;gt;dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh-&amp;gt;arp_queue of the bridge. As skb-&amp;gt;dev can be reset back to nf_bridge-&amp;gt;physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn&amp;#39;t cleanup skbs from different device&amp;#39;s neigh queue) we can crash on e.g. this stack: arp_process   neigh_update     skb = __skb_dequeue(&amp;amp;neigh-&amp;gt;arp_queue)       neigh_resolve_output(..., skb)         ...           br_nf_dev_xmit             br_nf_pre_routing_finish_bridge_slow               skb-&amp;gt;dev = nf_bridge-&amp;gt;physindev               br_handle_frame_finish Let&amp;#39;s use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don&amp;#39;t get it and drop skb.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35839</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1188 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188</guid>
    </item>
  </channel>
</rss>
