<?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>Mon, 05 Oct 2026 02:01:04 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-00806</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-00806</link>
      <description>bdu:2025-00806</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-00806</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-320207</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320207</link>
      <description>EUVD-2026-320207</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320207</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47024</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47024</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vsock/virtio: free queued packets when closing socket&lt;/p&gt;
&lt;p&gt;As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
(&amp;#34;vsock/virtio: free packets during the socket release&amp;#34;), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.&lt;/p&gt;
&lt;p&gt;To avoid future issues, let&amp;#39;s use the new virtio_transport_remove_sock()
to drain the RX queue before removing the socket from the af_vsock lists
calling vsock_remove_sock().&lt;/p&gt;
&lt;p&gt;[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9&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;vsock/virtio: free queued packets when closing socket&lt;/p&gt;
&lt;p&gt;As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
(&amp;#34;vsock/virtio: free packets during the socket release&amp;#34;), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.&lt;/p&gt;
&lt;p&gt;To avoid future issues, let&amp;#39;s use the new virtio_transport_remove_sock()
to drain the RX queue before removing the socket from the af_vsock lists
calling vsock_remove_sock().&lt;/p&gt;
&lt;p&gt;[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47024</guid>
    </item>
    <item>
      <title>GHSA-wwcj-mm94-5r39</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-wwcj-mm94-5r39</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vsock/virtio: free queued packets when closing socket&lt;/p&gt;
&lt;p&gt;As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
(&amp;#34;vsock/virtio: free packets during the socket release&amp;#34;), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.&lt;/p&gt;
&lt;p&gt;To avoid future issues, let&amp;#39;s use the new virtio_transport_remove_sock()
to drain the RX queue before removing the socket from the af_vsock lists
calling vsock_remove_sock().&lt;/p&gt;
&lt;p&gt;[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9&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;vsock/virtio: free queued packets when closing socket&lt;/p&gt;
&lt;p&gt;As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
(&amp;#34;vsock/virtio: free packets during the socket release&amp;#34;), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.&lt;/p&gt;
&lt;p&gt;To avoid future issues, let&amp;#39;s use the new virtio_transport_remove_sock()
to drain the RX queue before removing the socket from the af_vsock lists
calling vsock_remove_sock().&lt;/p&gt;
&lt;p&gt;[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-wwcj-mm94-5r39</guid>
    </item>
    <item>
      <title>gsd-2021-47024</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-47024</link>
      <description>gsd-2021-47024</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-47024</guid>
    </item>
    <item>
      <title>OESA-2024-1345 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1345</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: xiic: fix reference leak when pm_runtime_get_sync fails&#13;
&#13;
The PM reference count is not expected to be incremented on
return in xiic_xfer and xiic_i2c_remove.&#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-36778)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails&#13;
&#13;
The PM reference count is not expected to be incremented on
return in lpi2c_imx_master_enable.&#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-36782)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
HID: usbhid: fix info leak in hid_submit_ctrl&#13;
&#13;
In hid_submit_ctrl(), the way of calculating the report length doesn&amp;amp;apos;t
take into account that report-&amp;amp;gt;size can be zero. When running the
syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to
calculate transfer_buffer_length as 16384. When this urb is passed to
the usb core layer, KMSAN reports an info leak of 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: xiic: fix reference leak when pm_runtime_get_sync fails&#13;
&#13;
The PM reference count is not expected to be incremented on
return in xiic_xfer and xiic_i2c_remove.&#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-36778)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails&#13;
&#13;
The PM reference count is not expected to be incremented on
return in lpi2c_imx_master_enable.&#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-36782)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
HID: usbhid: fix info leak in hid_submit_ctrl&#13;
&#13;
In hid_submit_ctrl(), the way of calculating the report length doesn&amp;amp;apos;t
take into account that report-&amp;amp;gt;size can be zero. When running the
syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to
calculate transfer_buffer_length as 16384. When this urb is passed to
the usb core layer, KMSAN reports an info leak of 1…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1345</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-47024</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47024</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 101 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b (&amp;#34;vsock/virtio: free packets during the socket release&amp;#34;), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let&amp;#39;s use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9&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: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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 101 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b (&amp;#34;vsock/virtio: free packets during the socket release&amp;#34;), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let&amp;#39;s use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47024</guid>
    </item>
  </channel>
</rss>
