<?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 05:35:51 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-13709</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-13709</link>
      <description>bdu:2025-13709</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-13709</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0363 — De multiples vulnérabilités ont été découvertes dans &lt;span
class="textit"&gt;le noyau Linux de SUSE&lt;/span&gt;. Certaines d'en…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0363</link>
      <description>certfr-2024-avi-0363</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0363</guid>
    </item>
    <item>
      <title>EUVD-2026-309576</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309576</link>
      <description>EUVD-2026-309576</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309576</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47170</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47170</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;USB: usbfs: Don&amp;#39;t WARN about excessively large memory allocations&lt;/p&gt;
&lt;p&gt;Syzbot found that the kernel generates a WARNing if the user tries to
submit a bulk transfer through usbfs with a buffer that is way too
large.  This isn&amp;#39;t a bug in the kernel; it&amp;#39;s merely an invalid request
from the user and the usbfs code does handle it correctly.&lt;/p&gt;
&lt;p&gt;In theory the same thing can happen with async transfers, or with the
packet descriptor table for isochronous transfers.&lt;/p&gt;
&lt;p&gt;To prevent the MM subsystem from complaining about these bad
allocation requests, add the __GFP_NOWARN flag to the kmalloc calls
for these buffers.&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;USB: usbfs: Don&amp;#39;t WARN about excessively large memory allocations&lt;/p&gt;
&lt;p&gt;Syzbot found that the kernel generates a WARNing if the user tries to
submit a bulk transfer through usbfs with a buffer that is way too
large.  This isn&amp;#39;t a bug in the kernel; it&amp;#39;s merely an invalid request
from the user and the usbfs code does handle it correctly.&lt;/p&gt;
&lt;p&gt;In theory the same thing can happen with async transfers, or with the
packet descriptor table for isochronous transfers.&lt;/p&gt;
&lt;p&gt;To prevent the MM subsystem from complaining about these bad
allocation requests, add the __GFP_NOWARN flag to the kmalloc calls
for these buffers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47170</guid>
    </item>
    <item>
      <title>GHSA-c673-578f-v4xm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-c673-578f-v4xm</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;USB: usbfs: Don&amp;#39;t WARN about excessively large memory allocations&lt;/p&gt;
&lt;p&gt;Syzbot found that the kernel generates a WARNing if the user tries to
submit a bulk transfer through usbfs with a buffer that is way too
large.  This isn&amp;#39;t a bug in the kernel; it&amp;#39;s merely an invalid request
from the user and the usbfs code does handle it correctly.&lt;/p&gt;
&lt;p&gt;In theory the same thing can happen with async transfers, or with the
packet descriptor table for isochronous transfers.&lt;/p&gt;
&lt;p&gt;To prevent the MM subsystem from complaining about these bad
allocation requests, add the __GFP_NOWARN flag to the kmalloc calls
for these buffers.&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;USB: usbfs: Don&amp;#39;t WARN about excessively large memory allocations&lt;/p&gt;
&lt;p&gt;Syzbot found that the kernel generates a WARNing if the user tries to
submit a bulk transfer through usbfs with a buffer that is way too
large.  This isn&amp;#39;t a bug in the kernel; it&amp;#39;s merely an invalid request
from the user and the usbfs code does handle it correctly.&lt;/p&gt;
&lt;p&gt;In theory the same thing can happen with async transfers, or with the
packet descriptor table for isochronous transfers.&lt;/p&gt;
&lt;p&gt;To prevent the MM subsystem from complaining about these bad
allocation requests, add the __GFP_NOWARN flag to the kmalloc calls
for these buffers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-c673-578f-v4xm</guid>
    </item>
    <item>
      <title>gsd-2021-47170</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-47170</link>
      <description>gsd-2021-47170</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-47170</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:1454-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:1454-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:1454-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-47170</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47170</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, 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 and 108 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: USB: usbfs: Don&amp;#39;t WARN about excessively large memory allocations Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large.  This isn&amp;#39;t a bug in the kernel; it&amp;#39;s merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers.&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, 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 and 108 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: USB: usbfs: Don&amp;#39;t WARN about excessively large memory allocations Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large.  This isn&amp;#39;t a bug in the kernel; it&amp;#39;s merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47170</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>
