<?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 03:18:18 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-13704</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-13704</link>
      <description>bdu:2025-13704</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-13704</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0420 — 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-0420</link>
      <description>certfr-2024-avi-0420</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0420</guid>
    </item>
    <item>
      <title>EUVD-2026-344408</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344408</link>
      <description>EUVD-2026-344408</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344408</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47162</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47162</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tipc: skb_linearize the head skb when reassembling msgs&lt;/p&gt;
&lt;p&gt;It&amp;#39;s not a good idea to append the frag skb to a skb&amp;#39;s frag_list if
the frag_list already has skbs from elsewhere, such as this skb was
created by pskb_copy() where the frag_list was cloned (all the skbs
in it were skb_get&amp;#39;ed) and shared by multiple skbs.&lt;/p&gt;
&lt;p&gt;However, the new appended frag skb should have been only seen by the
current skb. Otherwise, it will cause use after free crashes as this
appended frag skb are seen by multiple skbs but it only got skb_get
called once.&lt;/p&gt;
&lt;p&gt;The same thing happens with a skb updated by pskb_may_pull() with a
skb_cloned skb. Li Shuang has reported quite a few crashes caused
by this when doing testing over macvlan devices:&lt;/p&gt;
&lt;p&gt;[] kernel BUG at net/core/skbuff.c:1970!
  [] Call Trace:
  []  skb_clone+0x4d/0xb0
  []  macvlan_broadcast+0xd8/0x160 [macvlan]
  []  macvlan_process_broadcast+0x148/0x150 [macvlan]
  []  process_one_work+0x1a7/0x360
  []  worker_thread+0x30/0x390&lt;/p&gt;
&lt;p&gt;[] kernel BUG at mm/usercopy.c:102!
  [] Call Trace:
  []  __check_heap_object+0xd3/0x100
  []  __check_object_size+0xff/0x16b
  []  simple_copy_to_iter+0x1c/0x30
  []  __skb_datagram_iter+0x7d/0x310
  []  __skb_datagram_iter+0x2a5/0x310
  []  skb_copy_datagram_iter+0x3b/0x90
  []  tipc_recvmsg+0x14a/0x3a0 [tipc]
  []  ____sys_recvmsg+0x91/0x150
  []  ___sys_recvmsg+0x7b/0xc0&lt;/p&gt;
&lt;p&gt;[] kernel BUG at mm/slub.c:305!
  [] Call Trace:
  []  &amp;lt;IRQ&amp;gt;
  []  kmem_cach…&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;tipc: skb_linearize the head skb when reassembling msgs&lt;/p&gt;
&lt;p&gt;It&amp;#39;s not a good idea to append the frag skb to a skb&amp;#39;s frag_list if
the frag_list already has skbs from elsewhere, such as this skb was
created by pskb_copy() where the frag_list was cloned (all the skbs
in it were skb_get&amp;#39;ed) and shared by multiple skbs.&lt;/p&gt;
&lt;p&gt;However, the new appended frag skb should have been only seen by the
current skb. Otherwise, it will cause use after free crashes as this
appended frag skb are seen by multiple skbs but it only got skb_get
called once.&lt;/p&gt;
&lt;p&gt;The same thing happens with a skb updated by pskb_may_pull() with a
skb_cloned skb. Li Shuang has reported quite a few crashes caused
by this when doing testing over macvlan devices:&lt;/p&gt;
&lt;p&gt;[] kernel BUG at net/core/skbuff.c:1970!
  [] Call Trace:
  []  skb_clone+0x4d/0xb0
  []  macvlan_broadcast+0xd8/0x160 [macvlan]
  []  macvlan_process_broadcast+0x148/0x150 [macvlan]
  []  process_one_work+0x1a7/0x360
  []  worker_thread+0x30/0x390&lt;/p&gt;
&lt;p&gt;[] kernel BUG at mm/usercopy.c:102!
  [] Call Trace:
  []  __check_heap_object+0xd3/0x100
  []  __check_object_size+0xff/0x16b
  []  simple_copy_to_iter+0x1c/0x30
  []  __skb_datagram_iter+0x7d/0x310
  []  __skb_datagram_iter+0x2a5/0x310
  []  skb_copy_datagram_iter+0x3b/0x90
  []  tipc_recvmsg+0x14a/0x3a0 [tipc]
  []  ____sys_recvmsg+0x91/0x150
  []  ___sys_recvmsg+0x7b/0xc0&lt;/p&gt;
&lt;p&gt;[] kernel BUG at mm/slub.c:305!
  [] Call Trace:
  []  &amp;lt;IRQ&amp;gt;
  []  kmem_cach…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47162</guid>
    </item>
    <item>
      <title>GHSA-86fr-x2qv-cxp5</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-86fr-x2qv-cxp5</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tipc: skb_linearize the head skb when reassembling msgs&lt;/p&gt;
&lt;p&gt;It&amp;#39;s not a good idea to append the frag skb to a skb&amp;#39;s frag_list if
the frag_list already has skbs from elsewhere, such as this skb was
created by pskb_copy() where the frag_list was cloned (all the skbs
in it were skb_get&amp;#39;ed) and shared by multiple skbs.&lt;/p&gt;
&lt;p&gt;However, the new appended frag skb should have been only seen by the
current skb. Otherwise, it will cause use after free crashes as this
appended frag skb are seen by multiple skbs but it only got skb_get
called once.&lt;/p&gt;
&lt;p&gt;The same thing happens with a skb updated by pskb_may_pull() with a
skb_cloned skb. Li Shuang has reported quite a few crashes caused
by this when doing testing over macvlan devices:&lt;/p&gt;
&lt;p&gt;[] kernel BUG at net/core/skbuff.c:1970!
  [] Call Trace:
  []  skb_clone+0x4d/0xb0
  []  macvlan_broadcast+0xd8/0x160 [macvlan]
  []  macvlan_process_broadcast+0x148/0x150 [macvlan]
  []  process_one_work+0x1a7/0x360
  []  worker_thread+0x30/0x390&lt;/p&gt;
&lt;p&gt;[] kernel BUG at mm/usercopy.c:102!
  [] Call Trace:
  []  __check_heap_object+0xd3/0x100
  []  __check_object_size+0xff/0x16b
  []  simple_copy_to_iter+0x1c/0x30
  []  __skb_datagram_iter+0x7d/0x310
  []  __skb_datagram_iter+0x2a5/0x310
  []  skb_copy_datagram_iter+0x3b/0x90
  []  tipc_recvmsg+0x14a/0x3a0 [tipc]
  []  ____sys_recvmsg+0x91/0x150
  []  ___sys_recvmsg+0x7b/0xc0&lt;/p&gt;
&lt;p&gt;[] kernel BUG at mm/slub.c:305!
  [] Call Trace:
  []  &amp;lt;IRQ&amp;gt;
  []  kmem_cach…&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;tipc: skb_linearize the head skb when reassembling msgs&lt;/p&gt;
&lt;p&gt;It&amp;#39;s not a good idea to append the frag skb to a skb&amp;#39;s frag_list if
the frag_list already has skbs from elsewhere, such as this skb was
created by pskb_copy() where the frag_list was cloned (all the skbs
in it were skb_get&amp;#39;ed) and shared by multiple skbs.&lt;/p&gt;
&lt;p&gt;However, the new appended frag skb should have been only seen by the
current skb. Otherwise, it will cause use after free crashes as this
appended frag skb are seen by multiple skbs but it only got skb_get
called once.&lt;/p&gt;
&lt;p&gt;The same thing happens with a skb updated by pskb_may_pull() with a
skb_cloned skb. Li Shuang has reported quite a few crashes caused
by this when doing testing over macvlan devices:&lt;/p&gt;
&lt;p&gt;[] kernel BUG at net/core/skbuff.c:1970!
  [] Call Trace:
  []  skb_clone+0x4d/0xb0
  []  macvlan_broadcast+0xd8/0x160 [macvlan]
  []  macvlan_process_broadcast+0x148/0x150 [macvlan]
  []  process_one_work+0x1a7/0x360
  []  worker_thread+0x30/0x390&lt;/p&gt;
&lt;p&gt;[] kernel BUG at mm/usercopy.c:102!
  [] Call Trace:
  []  __check_heap_object+0xd3/0x100
  []  __check_object_size+0xff/0x16b
  []  simple_copy_to_iter+0x1c/0x30
  []  __skb_datagram_iter+0x7d/0x310
  []  __skb_datagram_iter+0x2a5/0x310
  []  skb_copy_datagram_iter+0x3b/0x90
  []  tipc_recvmsg+0x14a/0x3a0 [tipc]
  []  ____sys_recvmsg+0x91/0x150
  []  ___sys_recvmsg+0x7b/0xc0&lt;/p&gt;
&lt;p&gt;[] kernel BUG at mm/slub.c:305!
  [] Call Trace:
  []  &amp;lt;IRQ&amp;gt;
  []  kmem_cach…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-86fr-x2qv-cxp5</guid>
    </item>
    <item>
      <title>gsd-2021-47162</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-47162</link>
      <description>gsd-2021-47162</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-47162</guid>
    </item>
    <item>
      <title>OESA-2024-1483 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1483</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP1: 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;
i2c: img-scb: fix reference leak when pm_runtime_get_sync fails&#13;
&#13;
The PM reference count is not expected to be incremented on
return in functions img_i2c_xfer and img_i2c_init.&#13;
&#13;
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.&#13;
&#13;
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.(CVE-2020-36783)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
kyber: fix out of bounds access when preempted&#13;
&#13;
__blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and
passes the hctx to -&amp;amp;gt;bio_merge(). kyber_bio_merge() then gets the ctx
for the current CPU again and uses that to get the corresponding Kyber
context in the passed hctx. However, the thread may be preempted between
the two calls to blk_mq_get_ctx(), and the ctx returned the second time
may no longer correspond to the passed hctx. This &amp;amp;quot;works&amp;amp;quot; accidentally
most of the time, but it can cause us to read garbage if the second ctx
came from an hctx with more ctx&amp;amp;apos;s than the first one (i.e., if
ctx-&amp;amp;gt;index_hw[hctx-&amp;amp;gt;type] &amp;amp;gt; hctx-&amp;amp;gt;nr_ctx).&#13;
&#13;
This manifested as this UBSAN array index out of bounds error reported
by Jakub:&#13;
&#13;
UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9
index 1…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP1: 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;
i2c: img-scb: fix reference leak when pm_runtime_get_sync fails&#13;
&#13;
The PM reference count is not expected to be incremented on
return in functions img_i2c_xfer and img_i2c_init.&#13;
&#13;
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.&#13;
&#13;
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.(CVE-2020-36783)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
kyber: fix out of bounds access when preempted&#13;
&#13;
__blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and
passes the hctx to -&amp;amp;gt;bio_merge(). kyber_bio_merge() then gets the ctx
for the current CPU again and uses that to get the corresponding Kyber
context in the passed hctx. However, the thread may be preempted between
the two calls to blk_mq_get_ctx(), and the ctx returned the second time
may no longer correspond to the passed hctx. This &amp;amp;quot;works&amp;amp;quot; accidentally
most of the time, but it can cause us to read garbage if the second ctx
came from an hctx with more ctx&amp;amp;apos;s than the first one (i.e., if
ctx-&amp;amp;gt;index_hw[hctx-&amp;amp;gt;type] &amp;amp;gt; hctx-&amp;amp;gt;nr_ctx).&#13;
&#13;
This manifested as this UBSAN array index out of bounds error reported
by Jakub:&#13;
&#13;
UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9
index 1…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1483</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:1643-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:1643-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:1643-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-47162</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47162</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 106 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tipc: skb_linearize the head skb when reassembling msgs It&amp;#39;s not a good idea to append the frag skb to a skb&amp;#39;s frag_list if the frag_list already has skbs from elsewhere, such as this skb was created by pskb_copy() where the frag_list was cloned (all the skbs in it were skb_get&amp;#39;ed) and shared by multiple skbs. However, the new appended frag skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes as this appended frag skb are seen by multiple skbs but it only got skb_get called once. The same thing happens with a skb updated by pskb_may_pull() with a skb_cloned skb. Li Shuang has reported quite a few crashes caused by this when doing testing over macvlan devices:   [] kernel BUG at net/core/skbuff.c:1970!   [] Call Trace:   []  skb_clone+0x4d/0xb0   []  macvlan_broadcast+0xd8/0x160 [macvlan]   []  macvlan_process_broadcast+0x148/0x150 [macvlan]   []  process_one_work+0x1a7/0x360   []  worker_thread+0x30/0x390   [] kernel BUG at mm/usercopy.c:102!   [] Call Trace:   []  __check_heap_object+0xd3/0x100   []  __check_object_size+0xff/0x16b   []  simple_copy_to_iter+0x1c/0x30   []  __skb_datagram_iter+0x7d/0x310   []  __skb_datagram_iter+0x2a5/0x310   []  skb_copy_datagram_iter+0x3b/0x90   []  tipc_recvmsg+0x14a/0x3a0 [tipc]   []  ____sys_recvmsg+0x91/0x150   []  ___sys_recvmsg+0x7b/0xc0   [] kernel BUG at mm/slub.c:305!   [] Call Trace:   []  &amp;lt;IRQ&amp;gt;   []  kmem_cache_free+…&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 106 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tipc: skb_linearize the head skb when reassembling msgs It&amp;#39;s not a good idea to append the frag skb to a skb&amp;#39;s frag_list if the frag_list already has skbs from elsewhere, such as this skb was created by pskb_copy() where the frag_list was cloned (all the skbs in it were skb_get&amp;#39;ed) and shared by multiple skbs. However, the new appended frag skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes as this appended frag skb are seen by multiple skbs but it only got skb_get called once. The same thing happens with a skb updated by pskb_may_pull() with a skb_cloned skb. Li Shuang has reported quite a few crashes caused by this when doing testing over macvlan devices:   [] kernel BUG at net/core/skbuff.c:1970!   [] Call Trace:   []  skb_clone+0x4d/0xb0   []  macvlan_broadcast+0xd8/0x160 [macvlan]   []  macvlan_process_broadcast+0x148/0x150 [macvlan]   []  process_one_work+0x1a7/0x360   []  worker_thread+0x30/0x390   [] kernel BUG at mm/usercopy.c:102!   [] Call Trace:   []  __check_heap_object+0xd3/0x100   []  __check_object_size+0xff/0x16b   []  simple_copy_to_iter+0x1c/0x30   []  __skb_datagram_iter+0x7d/0x310   []  __skb_datagram_iter+0x2a5/0x310   []  skb_copy_datagram_iter+0x3b/0x90   []  tipc_recvmsg+0x14a/0x3a0 [tipc]   []  ____sys_recvmsg+0x91/0x150   []  ___sys_recvmsg+0x7b/0xc0   [] kernel BUG at mm/slub.c:305!   [] Call Trace:   []  &amp;lt;IRQ&amp;gt;   []  kmem_cache_free+…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47162</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0699 — Linux-Kernel: Mehrere Schwachstellen ermöglichen Denial of Service und unspezifische Angriffe</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0699</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen und einen nicht 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 Denial-of-Service-Zustand zu erzeugen und einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0699</guid>
    </item>
  </channel>
</rss>
