<?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 16:32:21 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-11550</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-11550</link>
      <description>bdu:2024-11550</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-11550</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-38598</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-38598</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-38598</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0527 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0527</link>
      <description>certfr-2024-avi-0527</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0527</guid>
    </item>
    <item>
      <title>EUVD-2026-320626</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320626</link>
      <description>EUVD-2026-320626</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320626</guid>
    </item>
    <item>
      <title>fkie_cve-2024-38598</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-38598</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;md: fix resync softlockup when bitmap size is less than array size&lt;/p&gt;
&lt;p&gt;Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:&lt;/p&gt;
&lt;p&gt;kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
 &amp;lt;TASK&amp;gt;
 md_bitmap_start_sync+0x6b/0xf0
 raid10_sync_request+0x25c/0x1b40 [raid10]
 md_do_sync+0x64b/0x1020
 md_thread+0xa7/0x170
 kthread+0xcf/0x100
 ret_from_fork+0x30/0x50
 ret_from_fork_asm+0x1a/0x30&lt;/p&gt;
&lt;p&gt;And the detailed process is as follows:&lt;/p&gt;
&lt;p&gt;md_do_sync
 j = mddev-&amp;gt;resync_min
 while (j &amp;lt; max_sectors)
  sectors = raid10_sync_request(mddev, j, &amp;amp;skipped)
   if (!md_bitmap_start_sync(..., &amp;amp;sync_blocks))
    // md_bitmap_start_sync set sync_blocks to 0
    return sync_blocks + sectors_skippe;
  // sectors = 0;
  j += sectors;
  // j never change&lt;/p&gt;
&lt;p&gt;Root cause is that commit 301867b1c168 (&amp;#34;md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter&amp;#34;) return early from
md_bitmap_get_counter(), without setting returned blocks.&lt;/p&gt;
&lt;p&gt;Fix this problem by always set returned blocks from
md_bitmap_get_counter&amp;#34;(), as it used to be.&lt;/p&gt;
&lt;p&gt;Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn&amp;#39;t match array size still need to be fixed.&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: fix resync softlockup when bitmap size is less than array size&lt;/p&gt;
&lt;p&gt;Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:&lt;/p&gt;
&lt;p&gt;kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
 &amp;lt;TASK&amp;gt;
 md_bitmap_start_sync+0x6b/0xf0
 raid10_sync_request+0x25c/0x1b40 [raid10]
 md_do_sync+0x64b/0x1020
 md_thread+0xa7/0x170
 kthread+0xcf/0x100
 ret_from_fork+0x30/0x50
 ret_from_fork_asm+0x1a/0x30&lt;/p&gt;
&lt;p&gt;And the detailed process is as follows:&lt;/p&gt;
&lt;p&gt;md_do_sync
 j = mddev-&amp;gt;resync_min
 while (j &amp;lt; max_sectors)
  sectors = raid10_sync_request(mddev, j, &amp;amp;skipped)
   if (!md_bitmap_start_sync(..., &amp;amp;sync_blocks))
    // md_bitmap_start_sync set sync_blocks to 0
    return sync_blocks + sectors_skippe;
  // sectors = 0;
  j += sectors;
  // j never change&lt;/p&gt;
&lt;p&gt;Root cause is that commit 301867b1c168 (&amp;#34;md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter&amp;#34;) return early from
md_bitmap_get_counter(), without setting returned blocks.&lt;/p&gt;
&lt;p&gt;Fix this problem by always set returned blocks from
md_bitmap_get_counter&amp;#34;(), as it used to be.&lt;/p&gt;
&lt;p&gt;Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn&amp;#39;t match array size still need to be fixed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-38598</guid>
    </item>
    <item>
      <title>GHSA-c8cc-57pq-936r</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-c8cc-57pq-936r</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;md: fix resync softlockup when bitmap size is less than array size&lt;/p&gt;
&lt;p&gt;Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:&lt;/p&gt;
&lt;p&gt;kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
 &amp;lt;TASK&amp;gt;
 md_bitmap_start_sync+0x6b/0xf0
 raid10_sync_request+0x25c/0x1b40 [raid10]
 md_do_sync+0x64b/0x1020
 md_thread+0xa7/0x170
 kthread+0xcf/0x100
 ret_from_fork+0x30/0x50
 ret_from_fork_asm+0x1a/0x30&lt;/p&gt;
&lt;p&gt;And the detailed process is as follows:&lt;/p&gt;
&lt;p&gt;md_do_sync
 j = mddev-&amp;gt;resync_min
 while (j &amp;lt; max_sectors)
  sectors = raid10_sync_request(mddev, j, &amp;amp;skipped)
   if (!md_bitmap_start_sync(..., &amp;amp;sync_blocks))
    // md_bitmap_start_sync set sync_blocks to 0
    return sync_blocks + sectors_skippe;
  // sectors = 0;
  j += sectors;
  // j never change&lt;/p&gt;
&lt;p&gt;Root cause is that commit 301867b1c168 (&amp;#34;md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter&amp;#34;) return early from
md_bitmap_get_counter(), without setting returned blocks.&lt;/p&gt;
&lt;p&gt;Fix this problem by always set returned blocks from
md_bitmap_get_counter&amp;#34;(), as it used to be.&lt;/p&gt;
&lt;p&gt;Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn&amp;#39;t match array size still need to be fixed.&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: fix resync softlockup when bitmap size is less than array size&lt;/p&gt;
&lt;p&gt;Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:&lt;/p&gt;
&lt;p&gt;kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
 &amp;lt;TASK&amp;gt;
 md_bitmap_start_sync+0x6b/0xf0
 raid10_sync_request+0x25c/0x1b40 [raid10]
 md_do_sync+0x64b/0x1020
 md_thread+0xa7/0x170
 kthread+0xcf/0x100
 ret_from_fork+0x30/0x50
 ret_from_fork_asm+0x1a/0x30&lt;/p&gt;
&lt;p&gt;And the detailed process is as follows:&lt;/p&gt;
&lt;p&gt;md_do_sync
 j = mddev-&amp;gt;resync_min
 while (j &amp;lt; max_sectors)
  sectors = raid10_sync_request(mddev, j, &amp;amp;skipped)
   if (!md_bitmap_start_sync(..., &amp;amp;sync_blocks))
    // md_bitmap_start_sync set sync_blocks to 0
    return sync_blocks + sectors_skippe;
  // sectors = 0;
  j += sectors;
  // j never change&lt;/p&gt;
&lt;p&gt;Root cause is that commit 301867b1c168 (&amp;#34;md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter&amp;#34;) return early from
md_bitmap_get_counter(), without setting returned blocks.&lt;/p&gt;
&lt;p&gt;Fix this problem by always set returned blocks from
md_bitmap_get_counter&amp;#34;(), as it used to be.&lt;/p&gt;
&lt;p&gt;Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn&amp;#39;t match array size still need to be fixed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-c8cc-57pq-936r</guid>
    </item>
    <item>
      <title>ICSA-23-348-10 — Siemens SIMATIC S7-1500</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-23-348-10</link>
      <description>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-23-348-10</guid>
    </item>
    <item>
      <title>OESA-2024-1836 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1836</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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;
media: lgdt3306a: Add a check against null-pointer-def&#13;
&#13;
The driver should check whether the client provides the platform_data.&#13;
&#13;
The following log reveals it:&#13;
&#13;
[   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;amp;lt;TASK&amp;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(CVE-2022-48772)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline&#13;
&#13;
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.&#13;
&#13;
When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector o…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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;
media: lgdt3306a: Add a check against null-pointer-def&#13;
&#13;
The driver should check whether the client provides the platform_data.&#13;
&#13;
The following log reveals it:&#13;
&#13;
[   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;amp;lt;TASK&amp;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(CVE-2022-48772)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline&#13;
&#13;
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.&#13;
&#13;
When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1836</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:6993 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:6993</link>
      <description>&lt;p&gt;kernel: virtio-net: Add validation for used length kernel: mISDN: fix possible use-after-free in HFC_cleanup() kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: proc/vmcore: fix clearing user buffer by properly using clear_user() kernel: cgroup: cgroup_get_from_id() must check the looked-up kn is a directory kernel: smb: client: fix potential OOBs in smb2_parse_contexts() kernel: uio: Fix use-after-free in uio_open kernel: net: fix possible store tearing in neigh_periodic_work() kernel: bonding: stop the device in bond_setup_by_slave() kernel: scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool kernel: platform/x86: wmi: Fix opening of char device kernel: tunnels: fix out of bounds access when building IPv6 PMTU error kernel: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove kernel: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() kernel: mptcp: fix data re-injection from stale subflow kernel: netfilter: nf_conntrack_h323: Add protection for bmp length out of range kernel: x86/xen: Add some null pointer checking to smp.c kernel: af_unix: Fix garbage collector racing against connect() 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: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_ti…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: virtio-net: Add validation for used length kernel: mISDN: fix possible use-after-free in HFC_cleanup() kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: proc/vmcore: fix clearing user buffer by properly using clear_user() kernel: cgroup: cgroup_get_from_id() must check the looked-up kn is a directory kernel: smb: client: fix potential OOBs in smb2_parse_contexts() kernel: uio: Fix use-after-free in uio_open kernel: net: fix possible store tearing in neigh_periodic_work() kernel: bonding: stop the device in bond_setup_by_slave() kernel: scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool kernel: platform/x86: wmi: Fix opening of char device kernel: tunnels: fix out of bounds access when building IPv6 PMTU error kernel: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove kernel: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() kernel: mptcp: fix data re-injection from stale subflow kernel: netfilter: nf_conntrack_h323: Add protection for bmp length out of range kernel: x86/xen: Add some null pointer checking to smp.c kernel: af_unix: Fix garbage collector racing against connect() 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: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_ti…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:6993</guid>
    </item>
    <item>
      <title>SSA-265688 — SSA-265688: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 TM MFP V1.1</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-265688</link>
      <description>&lt;p&gt;An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-265688</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2493-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2493-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:2493-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-38598</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-38598</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 151 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: md: fix resync softlockup when bitmap size is less than array size Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup: kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace:  &amp;lt;TASK&amp;gt;  md_bitmap_start_sync+0x6b/0xf0  raid10_sync_request+0x25c/0x1b40 [raid10]  md_do_sync+0x64b/0x1020  md_thread+0xa7/0x170  kthread+0xcf/0x100  ret_from_fork+0x30/0x50  ret_from_fork_asm+0x1a/0x30 And the detailed process is as follows: md_do_sync  j = mddev-&amp;gt;resync_min  while (j &amp;lt; max_sectors)   sectors = raid10_sync_request(mddev, j, &amp;amp;skipped)    if (!md_bitmap_start_sync(..., &amp;amp;sync_blocks))     // md_bitmap_start_sync set sync_blocks to 0     return sync_blocks + sectors_skippe;   // sectors = 0;   j += sectors;   // j never change Root cause is that commit 301867b1c168 (&amp;#34;md/raid10: check slab-out-of-bounds in md_bitmap_get_counter&amp;#34;) return early from md_bitmap_get_counter(), without setting returned blocks. Fix this problem by always set returned blocks from md_bitmap_get_counter&amp;#34;(), as it used to be. Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn&amp;#39;t match array size still need to be fixed.&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 151 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: md: fix resync softlockup when bitmap size is less than array size Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup: kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace:  &amp;lt;TASK&amp;gt;  md_bitmap_start_sync+0x6b/0xf0  raid10_sync_request+0x25c/0x1b40 [raid10]  md_do_sync+0x64b/0x1020  md_thread+0xa7/0x170  kthread+0xcf/0x100  ret_from_fork+0x30/0x50  ret_from_fork_asm+0x1a/0x30 And the detailed process is as follows: md_do_sync  j = mddev-&amp;gt;resync_min  while (j &amp;lt; max_sectors)   sectors = raid10_sync_request(mddev, j, &amp;amp;skipped)    if (!md_bitmap_start_sync(..., &amp;amp;sync_blocks))     // md_bitmap_start_sync set sync_blocks to 0     return sync_blocks + sectors_skippe;   // sectors = 0;   j += sectors;   // j never change Root cause is that commit 301867b1c168 (&amp;#34;md/raid10: check slab-out-of-bounds in md_bitmap_get_counter&amp;#34;) return early from md_bitmap_get_counter(), without setting returned blocks. Fix this problem by always set returned blocks from md_bitmap_get_counter&amp;#34;(), as it used to be. Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn&amp;#39;t match array size still need to be fixed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-38598</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1418 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1418</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher 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 nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1418</guid>
    </item>
  </channel>
</rss>
