<?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 22:39:40 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-09808</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-09808</link>
      <description>bdu:2024-09808</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-09808</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-52699</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-52699</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-2023-52699</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0496 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</link>
      <description>certfr-2024-avi-0496</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</guid>
    </item>
    <item>
      <title>EUVD-2026-311641</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-311641</link>
      <description>EUVD-2026-311641</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-311641</guid>
    </item>
    <item>
      <title>fkie_cve-2023-52699</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-52699</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sysv: don&amp;#39;t call sb_bread() with pointers_lock held&lt;/p&gt;
&lt;p&gt;syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.&lt;/p&gt;
&lt;p&gt;A &amp;#34;write_lock(&amp;amp;pointers_lock) =&amp;gt; read_lock(&amp;amp;pointers_lock) deadlock&amp;#34; bug
and a &amp;#34;sb_bread() with write_lock(&amp;amp;pointers_lock)&amp;#34; bug were introduced by
&amp;#34;Replace BKL for chain locking with sysvfs-private rwlock&amp;#34; in Linux 2.5.12.&lt;/p&gt;
&lt;p&gt;Then, &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a &amp;#34;sb_bread() with read_lock(&amp;amp;pointers_lock)&amp;#34; bug (which made
this problem easier to hit).&lt;/p&gt;
&lt;p&gt;Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; except that get_branch()
 from with find_shared() is called without write_lock(&amp;amp;pointers_lock).&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;sysv: don&amp;#39;t call sb_bread() with pointers_lock held&lt;/p&gt;
&lt;p&gt;syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.&lt;/p&gt;
&lt;p&gt;A &amp;#34;write_lock(&amp;amp;pointers_lock) =&amp;gt; read_lock(&amp;amp;pointers_lock) deadlock&amp;#34; bug
and a &amp;#34;sb_bread() with write_lock(&amp;amp;pointers_lock)&amp;#34; bug were introduced by
&amp;#34;Replace BKL for chain locking with sysvfs-private rwlock&amp;#34; in Linux 2.5.12.&lt;/p&gt;
&lt;p&gt;Then, &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a &amp;#34;sb_bread() with read_lock(&amp;amp;pointers_lock)&amp;#34; bug (which made
this problem easier to hit).&lt;/p&gt;
&lt;p&gt;Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; except that get_branch()
 from with find_shared() is called without write_lock(&amp;amp;pointers_lock).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-52699</guid>
    </item>
    <item>
      <title>GHSA-29pq-gr25-8674</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-29pq-gr25-8674</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sysv: don&amp;#39;t call sb_bread() with pointers_lock held&lt;/p&gt;
&lt;p&gt;syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.&lt;/p&gt;
&lt;p&gt;A &amp;#34;write_lock(&amp;amp;pointers_lock) =&amp;gt; read_lock(&amp;amp;pointers_lock) deadlock&amp;#34; bug
and a &amp;#34;sb_bread() with write_lock(&amp;amp;pointers_lock)&amp;#34; bug were introduced by
&amp;#34;Replace BKL for chain locking with sysvfs-private rwlock&amp;#34; in Linux 2.5.12.&lt;/p&gt;
&lt;p&gt;Then, &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a &amp;#34;sb_bread() with read_lock(&amp;amp;pointers_lock)&amp;#34; bug (which made
this problem easier to hit).&lt;/p&gt;
&lt;p&gt;Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; except that get_branch()
 from with find_shared() is called without write_lock(&amp;amp;pointers_lock).&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;sysv: don&amp;#39;t call sb_bread() with pointers_lock held&lt;/p&gt;
&lt;p&gt;syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.&lt;/p&gt;
&lt;p&gt;A &amp;#34;write_lock(&amp;amp;pointers_lock) =&amp;gt; read_lock(&amp;amp;pointers_lock) deadlock&amp;#34; bug
and a &amp;#34;sb_bread() with write_lock(&amp;amp;pointers_lock)&amp;#34; bug were introduced by
&amp;#34;Replace BKL for chain locking with sysvfs-private rwlock&amp;#34; in Linux 2.5.12.&lt;/p&gt;
&lt;p&gt;Then, &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a &amp;#34;sb_bread() with read_lock(&amp;amp;pointers_lock)&amp;#34; bug (which made
this problem easier to hit).&lt;/p&gt;
&lt;p&gt;Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; except that get_branch()
 from with find_shared() is called without write_lock(&amp;amp;pointers_lock).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-29pq-gr25-8674</guid>
    </item>
    <item>
      <title>gsd-2023-52699</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-52699</link>
      <description>gsd-2023-52699</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-52699</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-1692 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1692</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;
net: usb: fix possible use-after-free in smsc75xx_bind&#13;
&#13;
The commit 46a8b29c6306 (&amp;amp;quot;net: usb: fix memory leak in smsc75xx_bind&amp;amp;quot;)
fails to clean up the work scheduled in smsc75xx_reset-&amp;amp;gt;
smsc75xx_set_multicast, which leads to use-after-free if the work is
scheduled to start after the deallocation. In addition, this patch
also removes a dangling pointer - dev-&amp;amp;gt;data[0].&#13;
&#13;
This patch calls cancel_work_sync to cancel the scheduled work and set
the dangling pointer to NULL.(CVE-2021-47239)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
RDMA: Verify port when creating flow rule&#13;
&#13;
Validate port value provided by the user and with that remove no longer
needed validation by the driver.  The missing check in the mlx5_ib driver
could cause to the below oops.&#13;
&#13;
Call trace:
  _create_flow_rule+0x2d4/0xf28 [mlx5_ib]
  mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
  ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
  ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
  ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
  ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
  do_vfs_ioctl+0xd0/0xaf0
  ksys_ioctl+0x84/0xb4
  __arm64_sys_ioctl+0x28/0xc4
  el0_svc_common.constprop.3+0xa4/0x254
  el0_svc_handler+0x84/0xa0
  el0_svc+0x10/0x26c
 Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;
net: usb: fix possible use-after-free in smsc75xx_bind&#13;
&#13;
The commit 46a8b29c6306 (&amp;amp;quot;net: usb: fix memory leak in smsc75xx_bind&amp;amp;quot;)
fails to clean up the work scheduled in smsc75xx_reset-&amp;amp;gt;
smsc75xx_set_multicast, which leads to use-after-free if the work is
scheduled to start after the deallocation. In addition, this patch
also removes a dangling pointer - dev-&amp;amp;gt;data[0].&#13;
&#13;
This patch calls cancel_work_sync to cancel the scheduled work and set
the dangling pointer to NULL.(CVE-2021-47239)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
RDMA: Verify port when creating flow rule&#13;
&#13;
Validate port value provided by the user and with that remove no longer
needed validation by the driver.  The missing check in the mlx5_ib driver
could cause to the below oops.&#13;
&#13;
Call trace:
  _create_flow_rule+0x2d4/0xf28 [mlx5_ib]
  mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
  ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
  ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
  ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
  ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
  do_vfs_ioctl+0xd0/0xaf0
  ksys_ioctl+0x84/0xb4
  __arm64_sys_ioctl+0x28/0xc4
  el0_svc_common.constprop.3+0xa4/0x254
  el0_svc_handler+0x84/0xa0
  el0_svc+0x10/0x26c
 Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1692</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2008-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2008-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:2008-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-52699</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52699</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 178 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: sysv: don&amp;#39;t call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A &amp;#34;write_lock(&amp;amp;pointers_lock) =&amp;gt; read_lock(&amp;amp;pointers_lock) deadlock&amp;#34; bug and a &amp;#34;sb_bread() with write_lock(&amp;amp;pointers_lock)&amp;#34; bug were introduced by &amp;#34;Replace BKL for chain locking with sysvfs-private rwlock&amp;#34; in Linux 2.5.12. Then, &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a &amp;#34;sb_bread() with read_lock(&amp;amp;pointers_lock)&amp;#34; bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; except that get_branch()  from with find_shared() is called without write_lock(&amp;amp;pointers_lock).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 178 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: sysv: don&amp;#39;t call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A &amp;#34;write_lock(&amp;amp;pointers_lock) =&amp;gt; read_lock(&amp;amp;pointers_lock) deadlock&amp;#34; bug and a &amp;#34;sb_bread() with write_lock(&amp;amp;pointers_lock)&amp;#34; bug were introduced by &amp;#34;Replace BKL for chain locking with sysvfs-private rwlock&amp;#34; in Linux 2.5.12. Then, &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a &amp;#34;sb_bread() with read_lock(&amp;amp;pointers_lock)&amp;#34; bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of &amp;#34;[PATCH] err1-40: sysvfs locking fix&amp;#34; except that get_branch()  from with find_shared() is called without write_lock(&amp;amp;pointers_lock).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52699</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>
