<?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:55:37 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12278</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12278</link>
      <description>bdu:2026-12278</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12278</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-23113</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-23113</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-2026-23113</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0316 — De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0316</link>
      <description>certfr-2026-avi-0316</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0316</guid>
    </item>
    <item>
      <title>EUVD-2026-364665</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364665</link>
      <description>EUVD-2026-364665</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364665</guid>
    </item>
    <item>
      <title>fkie_cve-2026-23113</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-23113</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&lt;/p&gt;
&lt;p&gt;Currently this is checked before running the pending work. Normally this
is quite fine, as work items either end up blocking (which will create a
new worker for other items), or they complete fairly quickly. But syzbot
reports an issue where io-wq takes seemingly forever to exit, and with a
bit of debugging, this turns out to be because it queues a bunch of big
(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&amp;#39;t
support -&amp;gt;read_iter(), loop_rw_iter() ends up handling them. Each read
returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of
these pending, processing the whole chain can take a long time. Easily
longer than the syzbot uninterruptible sleep timeout of 140 seconds.
This then triggers a complaint off the io-wq exit path:&lt;/p&gt;
&lt;p&gt;INFO: task syz.4.135:6326 blocked for more than 143 seconds.
      Not tainted syzkaller #0
      Blocked by coredump.
&amp;#34;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#34; disables this message.
task:syz.4.135       state:D stack:26824 pid:6326  tgid:6324  ppid:5957   task_flags:0x400548 flags:0x00080000
Call Trace:
 &amp;lt;TASK&amp;gt;
 context_switch kernel/sched/core.c:5256 [inline]
 __schedule+0x1139/0x6150 kernel/sched/core.c:6863
 __schedule_loop kernel/sched/core.c:6945 [inline]
 schedule+0xe7/0x3a0 kernel/sched/core.c:6960
 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75
 do_wait_for…&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;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&lt;/p&gt;
&lt;p&gt;Currently this is checked before running the pending work. Normally this
is quite fine, as work items either end up blocking (which will create a
new worker for other items), or they complete fairly quickly. But syzbot
reports an issue where io-wq takes seemingly forever to exit, and with a
bit of debugging, this turns out to be because it queues a bunch of big
(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&amp;#39;t
support -&amp;gt;read_iter(), loop_rw_iter() ends up handling them. Each read
returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of
these pending, processing the whole chain can take a long time. Easily
longer than the syzbot uninterruptible sleep timeout of 140 seconds.
This then triggers a complaint off the io-wq exit path:&lt;/p&gt;
&lt;p&gt;INFO: task syz.4.135:6326 blocked for more than 143 seconds.
      Not tainted syzkaller #0
      Blocked by coredump.
&amp;#34;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#34; disables this message.
task:syz.4.135       state:D stack:26824 pid:6326  tgid:6324  ppid:5957   task_flags:0x400548 flags:0x00080000
Call Trace:
 &amp;lt;TASK&amp;gt;
 context_switch kernel/sched/core.c:5256 [inline]
 __schedule+0x1139/0x6150 kernel/sched/core.c:6863
 __schedule_loop kernel/sched/core.c:6945 [inline]
 schedule+0xe7/0x3a0 kernel/sched/core.c:6960
 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75
 do_wait_for…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-23113</guid>
    </item>
    <item>
      <title>GHSA-ccr5-8c2w-j2f4</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-ccr5-8c2w-j2f4</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&lt;/p&gt;
&lt;p&gt;Currently this is checked before running the pending work. Normally this
is quite fine, as work items either end up blocking (which will create a
new worker for other items), or they complete fairly quickly. But syzbot
reports an issue where io-wq takes seemingly forever to exit, and with a
bit of debugging, this turns out to be because it queues a bunch of big
(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&amp;#39;t
support -&amp;gt;read_iter(), loop_rw_iter() ends up handling them. Each read
returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of
these pending, processing the whole chain can take a long time. Easily
longer than the syzbot uninterruptible sleep timeout of 140 seconds.
This then triggers a complaint off the io-wq exit path:&lt;/p&gt;
&lt;p&gt;INFO: task syz.4.135:6326 blocked for more than 143 seconds.
      Not tainted syzkaller #0
      Blocked by coredump.
&amp;#34;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#34; disables this message.
task:syz.4.135       state:D stack:26824 pid:6326  tgid:6324  ppid:5957   task_flags:0x400548 flags:0x00080000
Call Trace:
 &amp;lt;TASK&amp;gt;
 context_switch kernel/sched/core.c:5256 [inline]
 __schedule+0x1139/0x6150 kernel/sched/core.c:6863
 __schedule_loop kernel/sched/core.c:6945 [inline]
 schedule+0xe7/0x3a0 kernel/sched/core.c:6960
 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75
 do_wait_for…&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;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&lt;/p&gt;
&lt;p&gt;Currently this is checked before running the pending work. Normally this
is quite fine, as work items either end up blocking (which will create a
new worker for other items), or they complete fairly quickly. But syzbot
reports an issue where io-wq takes seemingly forever to exit, and with a
bit of debugging, this turns out to be because it queues a bunch of big
(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&amp;#39;t
support -&amp;gt;read_iter(), loop_rw_iter() ends up handling them. Each read
returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of
these pending, processing the whole chain can take a long time. Easily
longer than the syzbot uninterruptible sleep timeout of 140 seconds.
This then triggers a complaint off the io-wq exit path:&lt;/p&gt;
&lt;p&gt;INFO: task syz.4.135:6326 blocked for more than 143 seconds.
      Not tainted syzkaller #0
      Blocked by coredump.
&amp;#34;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#34; disables this message.
task:syz.4.135       state:D stack:26824 pid:6326  tgid:6324  ppid:5957   task_flags:0x400548 flags:0x00080000
Call Trace:
 &amp;lt;TASK&amp;gt;
 context_switch kernel/sched/core.c:5256 [inline]
 __schedule+0x1139/0x6150 kernel/sched/core.c:6863
 __schedule_loop kernel/sched/core.c:6945 [inline]
 schedule+0xe7/0x3a0 kernel/sched/core.c:6960
 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75
 do_wait_for…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-ccr5-8c2w-j2f4</guid>
    </item>
    <item>
      <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-209-04</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-209-04</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-23113 — io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-23113</link>
      <description>msrc_CVE-2026-23113</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-23113</guid>
    </item>
    <item>
      <title>OESA-2026-1642 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-1642</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):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/xattr: missing fdput() in fremovexattr error path&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a
file reference but returns early without calling fdput() when
strncpy_from_user() fails on the name argument. In multi-threaded processes
where fdget() takes the slow path, this permanently leaks one
file reference per call, pinning the struct file and associated kernel
objects in memory. An unprivileged local user can exploit this to cause
kernel memory exhaustion. The issue was inadvertently fixed by commit
a71874379ec8 (&amp;amp;quot;xattr: switch to CLASS(fd)&amp;amp;quot;).(CVE-2024-14027)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pps: Fix a use-after-free&lt;/p&gt;
&lt;p&gt;On a board running ntpd and gpsd, I&amp;amp;apos;m seeing a consistent use-after-free
in sys_exit() from gpsd when rebooting:&lt;/p&gt;
&lt;p&gt;pps pps1: removed
    ------------[ cut here ]------------
    kobject: &amp;amp;apos;(null)&amp;amp;apos; (00000000db4bec24): is not initialized, yet kobject_put() is being called.
    WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150
    CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1
    Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : kobject_put+0x120/0x150
    lr : kobject_put+0x120/0x150
    sp :…&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):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/xattr: missing fdput() in fremovexattr error path&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a
file reference but returns early without calling fdput() when
strncpy_from_user() fails on the name argument. In multi-threaded processes
where fdget() takes the slow path, this permanently leaks one
file reference per call, pinning the struct file and associated kernel
objects in memory. An unprivileged local user can exploit this to cause
kernel memory exhaustion. The issue was inadvertently fixed by commit
a71874379ec8 (&amp;amp;quot;xattr: switch to CLASS(fd)&amp;amp;quot;).(CVE-2024-14027)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pps: Fix a use-after-free&lt;/p&gt;
&lt;p&gt;On a board running ntpd and gpsd, I&amp;amp;apos;m seeing a consistent use-after-free
in sys_exit() from gpsd when rebooting:&lt;/p&gt;
&lt;p&gt;pps pps1: removed
    ------------[ cut here ]------------
    kobject: &amp;amp;apos;(null)&amp;amp;apos; (00000000db4bec24): is not initialized, yet kobject_put() is being called.
    WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150
    CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1
    Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : kobject_put+0x120/0x150
    lr : kobject_put+0x120/0x150
    sp :…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-1642</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-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/opensuse-su-2026:21910-1</guid>
    </item>
    <item>
      <title>SSA-019113 — SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-019113</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-019113</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0962-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:0962-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-2026:0962-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-23113</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23113</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 232 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&amp;#39;t support -&amp;gt;read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds.       Not tainted syzkaller #0       Blocked by coredump. &amp;#34;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#34; disables this message. task:syz.4.135       state:D stack:26824 pid:6326  tgid:6324  ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace:  &amp;lt;TASK&amp;gt;  context_switch kernel/sched/core.c:5256 [inline]  __schedule+0x1139/0x6150 kernel/sched/core.c:6863  __schedule_loop kernel/sched/core.c:6945 [inline]  schedule+0xe7/0x3a0 kernel/sched/core.c:6960  schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75  do_wait_for_comm…&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 232 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&amp;#39;t support -&amp;gt;read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds.       Not tainted syzkaller #0       Blocked by coredump. &amp;#34;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#34; disables this message. task:syz.4.135       state:D stack:26824 pid:6326  tgid:6324  ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace:  &amp;lt;TASK&amp;gt;  context_switch kernel/sched/core.c:5256 [inline]  __schedule+0x1139/0x6150 kernel/sched/core.c:6863  __schedule_loop kernel/sched/core.c:6945 [inline]  schedule+0xe7/0x3a0 kernel/sched/core.c:6960  schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75  do_wait_for_comm…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23113</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0421 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0421</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0421</guid>
    </item>
  </channel>
</rss>
