<?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 11:50:44 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-03777</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-03777</link>
      <description>bdu:2026-03777</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-03777</guid>
    </item>
    <item>
      <title>EUVD-2026-344893</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344893</link>
      <description>EUVD-2026-344893</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344893</guid>
    </item>
    <item>
      <title>fkie_cve-2022-50335</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-50335</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;9p: set req refcount to zero to avoid uninitialized usage&lt;/p&gt;
&lt;p&gt;When a new request is allocated, the refcount will be zero if it is
reused, but if the request is newly allocated from slab, it is not fully
initialized before being added to idr.&lt;/p&gt;
&lt;p&gt;If the p9_read_work got a response before the refcount initiated. It will
use a uninitialized req, which will result in a bad request data struct.&lt;/p&gt;
&lt;p&gt;Here is the logs from syzbot.&lt;/p&gt;
&lt;p&gt;Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00
0x00 0x00 . . . . . . . . ] (in kfence-#110):
 p9_fcall_fini net/9p/client.c:248 [inline]
 p9_req_put net/9p/client.c:396 [inline]
 p9_req_put+0x208/0x250 net/9p/client.c:390
 p9_client_walk+0x247/0x540 net/9p/client.c:1165
 clone_fid fs/9p/fid.h:21 [inline]
 v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118
 v9fs_xattr_set fs/9p/xattr.c:100 [inline]
 v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159
 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216
 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277
 vfs_setxattr+0x143/0x340 fs/xattr.c:309
 setxattr+0x146/0x160 fs/xattr.c:617
 path_setxattr+0x197/0x1c0 fs/xattr.c:636
 __do_sys_setxattr fs/xattr.c:652 [inline]
 __se_sys_setxattr fs/xattr.c:648 [inline]
 __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178
 do_fast_syscall_32+…&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;9p: set req refcount to zero to avoid uninitialized usage&lt;/p&gt;
&lt;p&gt;When a new request is allocated, the refcount will be zero if it is
reused, but if the request is newly allocated from slab, it is not fully
initialized before being added to idr.&lt;/p&gt;
&lt;p&gt;If the p9_read_work got a response before the refcount initiated. It will
use a uninitialized req, which will result in a bad request data struct.&lt;/p&gt;
&lt;p&gt;Here is the logs from syzbot.&lt;/p&gt;
&lt;p&gt;Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00
0x00 0x00 . . . . . . . . ] (in kfence-#110):
 p9_fcall_fini net/9p/client.c:248 [inline]
 p9_req_put net/9p/client.c:396 [inline]
 p9_req_put+0x208/0x250 net/9p/client.c:390
 p9_client_walk+0x247/0x540 net/9p/client.c:1165
 clone_fid fs/9p/fid.h:21 [inline]
 v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118
 v9fs_xattr_set fs/9p/xattr.c:100 [inline]
 v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159
 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216
 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277
 vfs_setxattr+0x143/0x340 fs/xattr.c:309
 setxattr+0x146/0x160 fs/xattr.c:617
 path_setxattr+0x197/0x1c0 fs/xattr.c:636
 __do_sys_setxattr fs/xattr.c:652 [inline]
 __se_sys_setxattr fs/xattr.c:648 [inline]
 __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178
 do_fast_syscall_32+…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-50335</guid>
    </item>
    <item>
      <title>GHSA-pq2h-q77j-f595</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-pq2h-q77j-f595</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;9p: set req refcount to zero to avoid uninitialized usage&lt;/p&gt;
&lt;p&gt;When a new request is allocated, the refcount will be zero if it is
reused, but if the request is newly allocated from slab, it is not fully
initialized before being added to idr.&lt;/p&gt;
&lt;p&gt;If the p9_read_work got a response before the refcount initiated. It will
use a uninitialized req, which will result in a bad request data struct.&lt;/p&gt;
&lt;p&gt;Here is the logs from syzbot.&lt;/p&gt;
&lt;p&gt;Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00
0x00 0x00 . . . . . . . . ] (in kfence-#110):
 p9_fcall_fini net/9p/client.c:248 [inline]
 p9_req_put net/9p/client.c:396 [inline]
 p9_req_put+0x208/0x250 net/9p/client.c:390
 p9_client_walk+0x247/0x540 net/9p/client.c:1165
 clone_fid fs/9p/fid.h:21 [inline]
 v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118
 v9fs_xattr_set fs/9p/xattr.c:100 [inline]
 v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159
 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216
 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277
 vfs_setxattr+0x143/0x340 fs/xattr.c:309
 setxattr+0x146/0x160 fs/xattr.c:617
 path_setxattr+0x197/0x1c0 fs/xattr.c:636
 __do_sys_setxattr fs/xattr.c:652 [inline]
 __se_sys_setxattr fs/xattr.c:648 [inline]
 __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178
 do_fast_syscall_32+…&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;9p: set req refcount to zero to avoid uninitialized usage&lt;/p&gt;
&lt;p&gt;When a new request is allocated, the refcount will be zero if it is
reused, but if the request is newly allocated from slab, it is not fully
initialized before being added to idr.&lt;/p&gt;
&lt;p&gt;If the p9_read_work got a response before the refcount initiated. It will
use a uninitialized req, which will result in a bad request data struct.&lt;/p&gt;
&lt;p&gt;Here is the logs from syzbot.&lt;/p&gt;
&lt;p&gt;Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00
0x00 0x00 . . . . . . . . ] (in kfence-#110):
 p9_fcall_fini net/9p/client.c:248 [inline]
 p9_req_put net/9p/client.c:396 [inline]
 p9_req_put+0x208/0x250 net/9p/client.c:390
 p9_client_walk+0x247/0x540 net/9p/client.c:1165
 clone_fid fs/9p/fid.h:21 [inline]
 v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118
 v9fs_xattr_set fs/9p/xattr.c:100 [inline]
 v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159
 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216
 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277
 vfs_setxattr+0x143/0x340 fs/xattr.c:309
 setxattr+0x146/0x160 fs/xattr.c:617
 path_setxattr+0x197/0x1c0 fs/xattr.c:636
 __do_sys_setxattr fs/xattr.c:652 [inline]
 __se_sys_setxattr fs/xattr.c:648 [inline]
 __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178
 do_fast_syscall_32+…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-pq2h-q77j-f595</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-50335</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50335</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 130 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: 9p: set req refcount to zero to avoid uninitialized usage When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110):  p9_fcall_fini net/9p/client.c:248 [inline]  p9_req_put net/9p/client.c:396 [inline]  p9_req_put+0x208/0x250 net/9p/client.c:390  p9_client_walk+0x247/0x540 net/9p/client.c:1165  clone_fid fs/9p/fid.h:21 [inline]  v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118  v9fs_xattr_set fs/9p/xattr.c:100 [inline]  v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159  __vfs_setxattr+0x119/0x180 fs/xattr.c:182  __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216  __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277  vfs_setxattr+0x143/0x340 fs/xattr.c:309  setxattr+0x146/0x160 fs/xattr.c:617  path_setxattr+0x197/0x1c0 fs/xattr.c:636  __do_sys_setxattr fs/xattr.c:652 [inline]  __se_sys_setxattr fs/xattr.c:648 [inline]  __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648  do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]  __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178  do_fast_syscall_32+0x33/…&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 130 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: 9p: set req refcount to zero to avoid uninitialized usage When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110):  p9_fcall_fini net/9p/client.c:248 [inline]  p9_req_put net/9p/client.c:396 [inline]  p9_req_put+0x208/0x250 net/9p/client.c:390  p9_client_walk+0x247/0x540 net/9p/client.c:1165  clone_fid fs/9p/fid.h:21 [inline]  v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118  v9fs_xattr_set fs/9p/xattr.c:100 [inline]  v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159  __vfs_setxattr+0x119/0x180 fs/xattr.c:182  __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216  __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277  vfs_setxattr+0x143/0x340 fs/xattr.c:309  setxattr+0x146/0x160 fs/xattr.c:617  path_setxattr+0x197/0x1c0 fs/xattr.c:636  __do_sys_setxattr fs/xattr.c:652 [inline]  __se_sys_setxattr fs/xattr.c:648 [inline]  __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648  do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]  __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178  do_fast_syscall_32+0x33/…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50335</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2053 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2053</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2053</guid>
    </item>
  </channel>
</rss>
