<?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>Fri, 02 Oct 2026 17:18:16 +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:2024-06088</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-06088</link>
      <description>bdu:2024-06088</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-06088</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-39476</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-39476</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-39476</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0613 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613</link>
      <description>certfr-2024-avi-0613</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613</guid>
    </item>
    <item>
      <title>EUVD-2026-320635</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320635</link>
      <description>EUVD-2026-320635</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320635</guid>
    </item>
    <item>
      <title>fkie_cve-2024-39476</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-39476</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING&lt;/p&gt;
&lt;p&gt;Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 (&amp;#34;Revert &amp;#34;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d&amp;#34;&amp;#34;)&lt;/p&gt;
&lt;p&gt;However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can&amp;#39;t issue
from raid5d().&lt;/p&gt;
&lt;p&gt;Current implementation in raid5d() has a weird dependence:&lt;/p&gt;
&lt;p&gt;1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear
   MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;&lt;/p&gt;
&lt;p&gt;This behaviour is introduce before v2.6, and for consequence, if other
context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
&amp;#39;reconfig_mutex&amp;#39; is released.&lt;/p&gt;
&lt;p&gt;Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39;
is released. Meanwhile, the hang problem will be fixed as well.&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;md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING&lt;/p&gt;
&lt;p&gt;Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 (&amp;#34;Revert &amp;#34;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d&amp;#34;&amp;#34;)&lt;/p&gt;
&lt;p&gt;However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can&amp;#39;t issue
from raid5d().&lt;/p&gt;
&lt;p&gt;Current implementation in raid5d() has a weird dependence:&lt;/p&gt;
&lt;p&gt;1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear
   MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;&lt;/p&gt;
&lt;p&gt;This behaviour is introduce before v2.6, and for consequence, if other
context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
&amp;#39;reconfig_mutex&amp;#39; is released.&lt;/p&gt;
&lt;p&gt;Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39;
is released. Meanwhile, the hang problem will be fixed as well.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-39476</guid>
    </item>
    <item>
      <title>GHSA-wx95-q6gv-qpp4</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-wx95-q6gv-qpp4</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING&lt;/p&gt;
&lt;p&gt;Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 (&amp;#34;Revert &amp;#34;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d&amp;#34;&amp;#34;)&lt;/p&gt;
&lt;p&gt;However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can&amp;#39;t issue
from raid5d().&lt;/p&gt;
&lt;p&gt;Current implementation in raid5d() has a weird dependence:&lt;/p&gt;
&lt;p&gt;1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear
   MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;&lt;/p&gt;
&lt;p&gt;This behaviour is introduce before v2.6, and for consequence, if other
context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
&amp;#39;reconfig_mutex&amp;#39; is released.&lt;/p&gt;
&lt;p&gt;Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39;
is released. Meanwhile, the hang problem will be fixed as well.&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;md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING&lt;/p&gt;
&lt;p&gt;Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 (&amp;#34;Revert &amp;#34;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d&amp;#34;&amp;#34;)&lt;/p&gt;
&lt;p&gt;However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can&amp;#39;t issue
from raid5d().&lt;/p&gt;
&lt;p&gt;Current implementation in raid5d() has a weird dependence:&lt;/p&gt;
&lt;p&gt;1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear
   MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;&lt;/p&gt;
&lt;p&gt;This behaviour is introduce before v2.6, and for consequence, if other
context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
&amp;#39;reconfig_mutex&amp;#39; is released.&lt;/p&gt;
&lt;p&gt;Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39;
is released. Meanwhile, the hang problem will be fixed as well.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-wx95-q6gv-qpp4</guid>
    </item>
    <item>
      <title>ICSA-25-226-15 — Siemens SINEC OS</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-25-226-15</link>
      <description>&lt;p&gt;In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;firmware: arm_scmi: Harden accesses to the reset domains&lt;/p&gt;
&lt;p&gt;Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.&lt;/p&gt;
&lt;p&gt;Add an internal consistency check before any such domains descriptors
accesses. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: lgdt3306a: Add a check against null-pointer-def&lt;/p&gt;
&lt;p&gt;The driver should check whether the client provides the platform_data.&lt;/p&gt;
&lt;p&gt;The following log reveals it:&lt;/p&gt;
&lt;p&gt;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;lt;TASK&amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;firmware: arm_scmi: Harden accesses to the reset domains&lt;/p&gt;
&lt;p&gt;Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.&lt;/p&gt;
&lt;p&gt;Add an internal consistency check before any such domains descriptors
accesses. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: lgdt3306a: Add a check against null-pointer-def&lt;/p&gt;
&lt;p&gt;The driver should check whether the client provides the platform_data.&lt;/p&gt;
&lt;p&gt;The following log reveals it:&lt;/p&gt;
&lt;p&gt;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;lt;TASK&amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-25-226-15</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-39476 — md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-39476</link>
      <description>msrc_CVE-2024-39476</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-39476</guid>
    </item>
    <item>
      <title>OESA-2024-1941 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1941</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: 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;
clk: sunxi-ng: Unregister clocks/resets when unbinding&#13;
&#13;
Currently, unbinding a CCU driver unmaps the device&amp;amp;apos;s MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.&#13;
&#13;
This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.&#13;
&#13;
Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR&#13;
&#13;
In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).&#13;
&#13;
Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.&#13;
&#13;
[   71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010&#13;
&#13;
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: 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;
clk: sunxi-ng: Unregister clocks/resets when unbinding&#13;
&#13;
Currently, unbinding a CCU driver unmaps the device&amp;amp;apos;s MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.&#13;
&#13;
This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.&#13;
&#13;
Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR&#13;
&#13;
In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).&#13;
&#13;
Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.&#13;
&#13;
[   71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010&#13;
&#13;
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1941</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>SSA-613116 — SSA-613116: Multiple Vulnerabilities in Third-Party Components in SINEC OS before V3.1</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-613116</link>
      <description>&lt;p&gt;In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;firmware: arm_scmi: Harden accesses to the reset domains&lt;/p&gt;
&lt;p&gt;Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.&lt;/p&gt;
&lt;p&gt;Add an internal consistency check before any such domains descriptors
accesses. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: lgdt3306a: Add a check against null-pointer-def&lt;/p&gt;
&lt;p&gt;The driver should check whether the client provides the platform_data.&lt;/p&gt;
&lt;p&gt;The following log reveals it:&lt;/p&gt;
&lt;p&gt;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;lt;TASK&amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;firmware: arm_scmi: Harden accesses to the reset domains&lt;/p&gt;
&lt;p&gt;Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.&lt;/p&gt;
&lt;p&gt;Add an internal consistency check before any such domains descriptors
accesses. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: lgdt3306a: Add a check against null-pointer-def&lt;/p&gt;
&lt;p&gt;The driver should check whether the client provides the platform_data.&lt;/p&gt;
&lt;p&gt;The following log reveals it:&lt;/p&gt;
&lt;p&gt;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;lt;TASK&amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-613116</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-39476</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-39476</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 143 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 (&amp;#34;Revert &amp;#34;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d&amp;#34;&amp;#34;) However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can&amp;#39;t issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear    MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update super_block, then raid5d() will waste one cpu 100% by the deadloop, until &amp;#39;reconfig_mutex&amp;#39; is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39; is released. Meanwhile, the hang problem will be fixed as well.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 143 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 (&amp;#34;Revert &amp;#34;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d&amp;#34;&amp;#34;) However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can&amp;#39;t issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear    MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update super_block, then raid5d() will waste one cpu 100% by the deadloop, until &amp;#39;reconfig_mutex&amp;#39; is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39; is released. Meanwhile, the hang problem will be fixed as well.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-39476</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1528 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1528</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen 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 zu erzeugen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1528</guid>
    </item>
  </channel>
</rss>
