<?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>Sun, 04 Oct 2026 00:07:38 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-03397</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-03397</link>
      <description>bdu:2026-03397</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-03397</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0587 — 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-2025-avi-0587</link>
      <description>certfr-2025-avi-0587</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0587</guid>
    </item>
    <item>
      <title>EUVD-2026-311011</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-311011</link>
      <description>EUVD-2026-311011</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-311011</guid>
    </item>
    <item>
      <title>fkie_cve-2022-50094</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-50094</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;spmi: trace: fix stack-out-of-bound access in SPMI tracing functions&lt;/p&gt;
&lt;p&gt;trace_spmi_write_begin() and trace_spmi_read_end() both call
memcpy() with a length of &amp;#34;len + 1&amp;#34;.  This leads to one extra
byte being read beyond the end of the specified buffer.  Fix
this out-of-bound memory access by using a length of &amp;#34;len&amp;#34;
instead.&lt;/p&gt;
&lt;p&gt;Here is a KASAN log showing the issue:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234
Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314
...
Call trace:
 dump_backtrace+0x0/0x3e8
 show_stack+0x2c/0x3c
 dump_stack_lvl+0xdc/0x11c
 print_address_description+0x74/0x384
 kasan_report+0x188/0x268
 kasan_check_range+0x270/0x2b0
 memcpy+0x90/0xe8
 trace_event_raw_event_spmi_read_end+0x1d0/0x234
 spmi_read_cmd+0x294/0x3ac
 spmi_ext_register_readl+0x84/0x9c
 regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]
 _regmap_raw_read+0x40c/0x754
 regmap_raw_read+0x3a0/0x514
 regmap_bulk_read+0x418/0x494
 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]
 ...
 __arm64_sys_read+0x4c/0x60
 invoke_syscall+0x80/0x218
 el0_svc_common+0xec/0x1c8
 ...&lt;/p&gt;
&lt;p&gt;addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:
 adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]&lt;/p&gt;
&lt;p&gt;this frame has 1 object:
 [32, 33) &amp;#39;status&amp;#39;&lt;/p&gt;
&lt;p&gt;Memory state around the buggy address:
 ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
 ffffffc026…&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;spmi: trace: fix stack-out-of-bound access in SPMI tracing functions&lt;/p&gt;
&lt;p&gt;trace_spmi_write_begin() and trace_spmi_read_end() both call
memcpy() with a length of &amp;#34;len + 1&amp;#34;.  This leads to one extra
byte being read beyond the end of the specified buffer.  Fix
this out-of-bound memory access by using a length of &amp;#34;len&amp;#34;
instead.&lt;/p&gt;
&lt;p&gt;Here is a KASAN log showing the issue:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234
Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314
...
Call trace:
 dump_backtrace+0x0/0x3e8
 show_stack+0x2c/0x3c
 dump_stack_lvl+0xdc/0x11c
 print_address_description+0x74/0x384
 kasan_report+0x188/0x268
 kasan_check_range+0x270/0x2b0
 memcpy+0x90/0xe8
 trace_event_raw_event_spmi_read_end+0x1d0/0x234
 spmi_read_cmd+0x294/0x3ac
 spmi_ext_register_readl+0x84/0x9c
 regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]
 _regmap_raw_read+0x40c/0x754
 regmap_raw_read+0x3a0/0x514
 regmap_bulk_read+0x418/0x494
 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]
 ...
 __arm64_sys_read+0x4c/0x60
 invoke_syscall+0x80/0x218
 el0_svc_common+0xec/0x1c8
 ...&lt;/p&gt;
&lt;p&gt;addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:
 adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]&lt;/p&gt;
&lt;p&gt;this frame has 1 object:
 [32, 33) &amp;#39;status&amp;#39;&lt;/p&gt;
&lt;p&gt;Memory state around the buggy address:
 ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
 ffffffc026…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-50094</guid>
    </item>
    <item>
      <title>GHSA-72wp-jhxv-vv38</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-72wp-jhxv-vv38</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;spmi: trace: fix stack-out-of-bound access in SPMI tracing functions&lt;/p&gt;
&lt;p&gt;trace_spmi_write_begin() and trace_spmi_read_end() both call
memcpy() with a length of &amp;#34;len + 1&amp;#34;.  This leads to one extra
byte being read beyond the end of the specified buffer.  Fix
this out-of-bound memory access by using a length of &amp;#34;len&amp;#34;
instead.&lt;/p&gt;
&lt;p&gt;Here is a KASAN log showing the issue:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234
Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314
...
Call trace:
 dump_backtrace+0x0/0x3e8
 show_stack+0x2c/0x3c
 dump_stack_lvl+0xdc/0x11c
 print_address_description+0x74/0x384
 kasan_report+0x188/0x268
 kasan_check_range+0x270/0x2b0
 memcpy+0x90/0xe8
 trace_event_raw_event_spmi_read_end+0x1d0/0x234
 spmi_read_cmd+0x294/0x3ac
 spmi_ext_register_readl+0x84/0x9c
 regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]
 _regmap_raw_read+0x40c/0x754
 regmap_raw_read+0x3a0/0x514
 regmap_bulk_read+0x418/0x494
 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]
 ...
 __arm64_sys_read+0x4c/0x60
 invoke_syscall+0x80/0x218
 el0_svc_common+0xec/0x1c8
 ...&lt;/p&gt;
&lt;p&gt;addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:
 adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]&lt;/p&gt;
&lt;p&gt;this frame has 1 object:
 [32, 33) &amp;#39;status&amp;#39;&lt;/p&gt;
&lt;p&gt;Memory state around the buggy address:
 ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
 ffffffc026…&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;spmi: trace: fix stack-out-of-bound access in SPMI tracing functions&lt;/p&gt;
&lt;p&gt;trace_spmi_write_begin() and trace_spmi_read_end() both call
memcpy() with a length of &amp;#34;len + 1&amp;#34;.  This leads to one extra
byte being read beyond the end of the specified buffer.  Fix
this out-of-bound memory access by using a length of &amp;#34;len&amp;#34;
instead.&lt;/p&gt;
&lt;p&gt;Here is a KASAN log showing the issue:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234
Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314
...
Call trace:
 dump_backtrace+0x0/0x3e8
 show_stack+0x2c/0x3c
 dump_stack_lvl+0xdc/0x11c
 print_address_description+0x74/0x384
 kasan_report+0x188/0x268
 kasan_check_range+0x270/0x2b0
 memcpy+0x90/0xe8
 trace_event_raw_event_spmi_read_end+0x1d0/0x234
 spmi_read_cmd+0x294/0x3ac
 spmi_ext_register_readl+0x84/0x9c
 regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]
 _regmap_raw_read+0x40c/0x754
 regmap_raw_read+0x3a0/0x514
 regmap_bulk_read+0x418/0x494
 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]
 ...
 __arm64_sys_read+0x4c/0x60
 invoke_syscall+0x80/0x218
 el0_svc_common+0xec/0x1c8
 ...&lt;/p&gt;
&lt;p&gt;addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:
 adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]&lt;/p&gt;
&lt;p&gt;this frame has 1 object:
 [32, 33) &amp;#39;status&amp;#39;&lt;/p&gt;
&lt;p&gt;Memory state around the buggy address:
 ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
 ffffffc026…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-72wp-jhxv-vv38</guid>
    </item>
    <item>
      <title>OESA-2025-1726 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1726</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):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kcm: close race conditions on sk_receive_queue&lt;/p&gt;
&lt;p&gt;sk-&amp;amp;gt;sk_receive_queue is protected by skb queue lock, but for KCM
sockets its RX path takes mux-&amp;amp;gt;rx_lock to protect more than just
skb queue. However, kcm_recvmsg() still only grabs the skb queue
lock, so race conditions still exist.&lt;/p&gt;
&lt;p&gt;We can teach kcm_recvmsg() to grab mux-&amp;amp;gt;rx_lock too but this would
introduce a potential performance regression as struct kcm_mux can
be shared by multiple KCM sockets.&lt;/p&gt;
&lt;p&gt;So we have to enforce skb queue lock in requeue_rx_msgs() and handle
skb peek case carefully in kcm_wait_data(). Fortunately,
skb_recv_datagram() already handles it nicely and is widely used by
other sockets, we can just switch to skb_recv_datagram() after
getting rid of the unnecessary sock lock in kcm_recvmsg() and
kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,
so it is safe to get rid of this check too.&lt;/p&gt;
&lt;p&gt;I ran the original syzbot reproducer for 30 min without seeing any
issue.(CVE-2022-49814)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipvs: fix WARNING in ip_vs_app_net_cleanup()&lt;/p&gt;
&lt;p&gt;During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn&amp;amp;apos;t be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.&lt;/p&gt;
&lt;p&gt;T…&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):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kcm: close race conditions on sk_receive_queue&lt;/p&gt;
&lt;p&gt;sk-&amp;amp;gt;sk_receive_queue is protected by skb queue lock, but for KCM
sockets its RX path takes mux-&amp;amp;gt;rx_lock to protect more than just
skb queue. However, kcm_recvmsg() still only grabs the skb queue
lock, so race conditions still exist.&lt;/p&gt;
&lt;p&gt;We can teach kcm_recvmsg() to grab mux-&amp;amp;gt;rx_lock too but this would
introduce a potential performance regression as struct kcm_mux can
be shared by multiple KCM sockets.&lt;/p&gt;
&lt;p&gt;So we have to enforce skb queue lock in requeue_rx_msgs() and handle
skb peek case carefully in kcm_wait_data(). Fortunately,
skb_recv_datagram() already handles it nicely and is widely used by
other sockets, we can just switch to skb_recv_datagram() after
getting rid of the unnecessary sock lock in kcm_recvmsg() and
kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,
so it is safe to get rid of this check too.&lt;/p&gt;
&lt;p&gt;I ran the original syzbot reproducer for 30 min without seeing any
issue.(CVE-2022-49814)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipvs: fix WARNING in ip_vs_app_net_cleanup()&lt;/p&gt;
&lt;p&gt;During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn&amp;amp;apos;t be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.&lt;/p&gt;
&lt;p&gt;T…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1726</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:02264-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:02264-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-2025:02264-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-50094</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50094</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws and 145 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: spmi: trace: fix stack-out-of-bound access in SPMI tracing functions trace_spmi_write_begin() and trace_spmi_read_end() both call memcpy() with a length of &amp;#34;len + 1&amp;#34;.  This leads to one extra byte being read beyond the end of the specified buffer.  Fix this out-of-bound memory access by using a length of &amp;#34;len&amp;#34; instead. Here is a KASAN log showing the issue: BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234 Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314 ... Call trace:  dump_backtrace+0x0/0x3e8  show_stack+0x2c/0x3c  dump_stack_lvl+0xdc/0x11c  print_address_description+0x74/0x384  kasan_report+0x188/0x268  kasan_check_range+0x270/0x2b0  memcpy+0x90/0xe8  trace_event_raw_event_spmi_read_end+0x1d0/0x234  spmi_read_cmd+0x294/0x3ac  spmi_ext_register_readl+0x84/0x9c  regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]  _regmap_raw_read+0x40c/0x754  regmap_raw_read+0x3a0/0x514  regmap_bulk_read+0x418/0x494  adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]  ...  __arm64_sys_read+0x4c/0x60  invoke_syscall+0x80/0x218  el0_svc_common+0xec/0x1c8  ... addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:  adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] this frame has 1 object:  [32, 33) &amp;#39;status&amp;#39; Memory state around the buggy address:  ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1  ffffffc0265b7480:…&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:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws and 145 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: spmi: trace: fix stack-out-of-bound access in SPMI tracing functions trace_spmi_write_begin() and trace_spmi_read_end() both call memcpy() with a length of &amp;#34;len + 1&amp;#34;.  This leads to one extra byte being read beyond the end of the specified buffer.  Fix this out-of-bound memory access by using a length of &amp;#34;len&amp;#34; instead. Here is a KASAN log showing the issue: BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234 Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314 ... Call trace:  dump_backtrace+0x0/0x3e8  show_stack+0x2c/0x3c  dump_stack_lvl+0xdc/0x11c  print_address_description+0x74/0x384  kasan_report+0x188/0x268  kasan_check_range+0x270/0x2b0  memcpy+0x90/0xe8  trace_event_raw_event_spmi_read_end+0x1d0/0x234  spmi_read_cmd+0x294/0x3ac  spmi_ext_register_readl+0x84/0x9c  regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]  _regmap_raw_read+0x40c/0x754  regmap_raw_read+0x3a0/0x514  regmap_bulk_read+0x418/0x494  adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]  ...  __arm64_sys_read+0x4c/0x60  invoke_syscall+0x80/0x218  el0_svc_common+0xec/0x1c8  ... addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:  adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] this frame has 1 object:  [32, 33) &amp;#39;status&amp;#39; Memory state around the buggy address:  ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1  ffffffc0265b7480:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50094</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1350 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350</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-2025-1350</guid>
    </item>
  </channel>
</rss>
