<?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:52:01 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-14289</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-14289</link>
      <description>bdu:2025-14289</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-14289</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-52636</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-52636</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-52636</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-345033</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345033</link>
      <description>EUVD-2026-345033</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345033</guid>
    </item>
    <item>
      <title>fkie_cve-2023-52636</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-52636</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;libceph: just wait for more data to be available on the socket&lt;/p&gt;
&lt;p&gt;A short read may occur while reading the message footer from the
socket.  Later, when the socket is ready for another read, the
messenger invokes all read_partial_*() handlers, including
read_partial_sparse_msg_data().  The expectation is that
read_partial_sparse_msg_data() would bail, allowing the messenger to
invoke read_partial() for the footer and pick up where it left off.&lt;/p&gt;
&lt;p&gt;However read_partial_sparse_msg_data() violates that and ends up
calling into the state machine in the OSD client.  The sparse-read
state machine assumes that it&amp;#39;s a new op and interprets some piece of
the footer as the sparse-read header and returns bogus extents/data
length, etc.&lt;/p&gt;
&lt;p&gt;To determine whether read_partial_sparse_msg_data() should bail, let&amp;#39;s
reuse cursor-&amp;gt;total_resid.  Because once it reaches to zero that means
all the extents and data have been successfully received in last read,
else it could break out when partially reading any of the extents and
data.  And then osd_sparse_read() could continue where it left off.&lt;/p&gt;
&lt;p&gt;[ idryomov: changelog ]&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;libceph: just wait for more data to be available on the socket&lt;/p&gt;
&lt;p&gt;A short read may occur while reading the message footer from the
socket.  Later, when the socket is ready for another read, the
messenger invokes all read_partial_*() handlers, including
read_partial_sparse_msg_data().  The expectation is that
read_partial_sparse_msg_data() would bail, allowing the messenger to
invoke read_partial() for the footer and pick up where it left off.&lt;/p&gt;
&lt;p&gt;However read_partial_sparse_msg_data() violates that and ends up
calling into the state machine in the OSD client.  The sparse-read
state machine assumes that it&amp;#39;s a new op and interprets some piece of
the footer as the sparse-read header and returns bogus extents/data
length, etc.&lt;/p&gt;
&lt;p&gt;To determine whether read_partial_sparse_msg_data() should bail, let&amp;#39;s
reuse cursor-&amp;gt;total_resid.  Because once it reaches to zero that means
all the extents and data have been successfully received in last read,
else it could break out when partially reading any of the extents and
data.  And then osd_sparse_read() could continue where it left off.&lt;/p&gt;
&lt;p&gt;[ idryomov: changelog ]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-52636</guid>
    </item>
    <item>
      <title>GHSA-fqg2-664v-fx4j</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-fqg2-664v-fx4j</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;libceph: just wait for more data to be available on the socket&lt;/p&gt;
&lt;p&gt;A short read may occur while reading the message footer from the
socket.  Later, when the socket is ready for another read, the
messenger invokes all read_partial_*() handlers, including
read_partial_sparse_msg_data().  The expectation is that
read_partial_sparse_msg_data() would bail, allowing the messenger to
invoke read_partial() for the footer and pick up where it left off.&lt;/p&gt;
&lt;p&gt;However read_partial_sparse_msg_data() violates that and ends up
calling into the state machine in the OSD client.  The sparse-read
state machine assumes that it&amp;#39;s a new op and interprets some piece of
the footer as the sparse-read header and returns bogus extents/data
length, etc.&lt;/p&gt;
&lt;p&gt;To determine whether read_partial_sparse_msg_data() should bail, let&amp;#39;s
reuse cursor-&amp;gt;total_resid.  Because once it reaches to zero that means
all the extents and data have been successfully received in last read,
else it could break out when partially reading any of the extents and
data.  And then osd_sparse_read() could continue where it left off.&lt;/p&gt;
&lt;p&gt;[ idryomov: changelog ]&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;libceph: just wait for more data to be available on the socket&lt;/p&gt;
&lt;p&gt;A short read may occur while reading the message footer from the
socket.  Later, when the socket is ready for another read, the
messenger invokes all read_partial_*() handlers, including
read_partial_sparse_msg_data().  The expectation is that
read_partial_sparse_msg_data() would bail, allowing the messenger to
invoke read_partial() for the footer and pick up where it left off.&lt;/p&gt;
&lt;p&gt;However read_partial_sparse_msg_data() violates that and ends up
calling into the state machine in the OSD client.  The sparse-read
state machine assumes that it&amp;#39;s a new op and interprets some piece of
the footer as the sparse-read header and returns bogus extents/data
length, etc.&lt;/p&gt;
&lt;p&gt;To determine whether read_partial_sparse_msg_data() should bail, let&amp;#39;s
reuse cursor-&amp;gt;total_resid.  Because once it reaches to zero that means
all the extents and data have been successfully received in last read,
else it could break out when partially reading any of the extents and
data.  And then osd_sparse_read() could continue where it left off.&lt;/p&gt;
&lt;p&gt;[ idryomov: changelog ]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-fqg2-664v-fx4j</guid>
    </item>
    <item>
      <title>gsd-2023-52636</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-52636</link>
      <description>gsd-2023-52636</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-52636</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:1490-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:1490-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:1490-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-52636</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52636</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 56 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: libceph: just wait for more data to be available on the socket A short read may occur while reading the message footer from the socket.  Later, when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including read_partial_sparse_msg_data().  The expectation is that read_partial_sparse_msg_data() would bail, allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client.  The sparse-read state machine assumes that it&amp;#39;s a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc. To determine whether read_partial_sparse_msg_data() should bail, let&amp;#39;s reuse cursor-&amp;gt;total_resid.  Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data.  And then osd_sparse_read() could continue where it left off. [ idryomov: changelog ]&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 56 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: libceph: just wait for more data to be available on the socket A short read may occur while reading the message footer from the socket.  Later, when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including read_partial_sparse_msg_data().  The expectation is that read_partial_sparse_msg_data() would bail, allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client.  The sparse-read state machine assumes that it&amp;#39;s a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc. To determine whether read_partial_sparse_msg_data() should bail, let&amp;#39;s reuse cursor-&amp;gt;total_resid.  Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data.  And then osd_sparse_read() could continue where it left off. [ idryomov: changelog ]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52636</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0749 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0749</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service oder einen nicht näher 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 oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0749</guid>
    </item>
  </channel>
</rss>
