<?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 12:09:39 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2023-53998</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53998</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-53998</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0108 — 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-2026-avi-0108</link>
      <description>certfr-2026-avi-0108</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108</guid>
    </item>
    <item>
      <title>EUVD-2026-312306</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-312306</link>
      <description>EUVD-2026-312306</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-312306</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53998</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53998</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;hwrng: virtio - Fix race on data_avail and actual data&lt;/p&gt;
&lt;p&gt;The virtio rng device kicks off a new entropy request whenever the
data available reaches zero.  When a new request occurs at the end
of a read operation, that is, when the result of that request is
only needed by the next reader, then there is a race between the
writing of the new data and the next reader.&lt;/p&gt;
&lt;p&gt;This is because there is no synchronisation whatsoever between the
writer and the reader.&lt;/p&gt;
&lt;p&gt;Fix this by writing data_avail with smp_store_release and reading
it with smp_load_acquire when we first enter read.  The subsequent
reads are safe because they&amp;#39;re either protected by the first load
acquire, or by the completion mechanism.&lt;/p&gt;
&lt;p&gt;Also remove the redundant zeroing of data_idx in random_recv_done
(data_idx must already be zero at this point) and data_avail in
request_entropy (ditto).&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;hwrng: virtio - Fix race on data_avail and actual data&lt;/p&gt;
&lt;p&gt;The virtio rng device kicks off a new entropy request whenever the
data available reaches zero.  When a new request occurs at the end
of a read operation, that is, when the result of that request is
only needed by the next reader, then there is a race between the
writing of the new data and the next reader.&lt;/p&gt;
&lt;p&gt;This is because there is no synchronisation whatsoever between the
writer and the reader.&lt;/p&gt;
&lt;p&gt;Fix this by writing data_avail with smp_store_release and reading
it with smp_load_acquire when we first enter read.  The subsequent
reads are safe because they&amp;#39;re either protected by the first load
acquire, or by the completion mechanism.&lt;/p&gt;
&lt;p&gt;Also remove the redundant zeroing of data_idx in random_recv_done
(data_idx must already be zero at this point) and data_avail in
request_entropy (ditto).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53998</guid>
    </item>
    <item>
      <title>GHSA-g2vv-m9x5-457j</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-g2vv-m9x5-457j</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;hwrng: virtio - Fix race on data_avail and actual data&lt;/p&gt;
&lt;p&gt;The virtio rng device kicks off a new entropy request whenever the
data available reaches zero.  When a new request occurs at the end
of a read operation, that is, when the result of that request is
only needed by the next reader, then there is a race between the
writing of the new data and the next reader.&lt;/p&gt;
&lt;p&gt;This is because there is no synchronisation whatsoever between the
writer and the reader.&lt;/p&gt;
&lt;p&gt;Fix this by writing data_avail with smp_store_release and reading
it with smp_load_acquire when we first enter read.  The subsequent
reads are safe because they&amp;#39;re either protected by the first load
acquire, or by the completion mechanism.&lt;/p&gt;
&lt;p&gt;Also remove the redundant zeroing of data_idx in random_recv_done
(data_idx must already be zero at this point) and data_avail in
request_entropy (ditto).&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;hwrng: virtio - Fix race on data_avail and actual data&lt;/p&gt;
&lt;p&gt;The virtio rng device kicks off a new entropy request whenever the
data available reaches zero.  When a new request occurs at the end
of a read operation, that is, when the result of that request is
only needed by the next reader, then there is a race between the
writing of the new data and the next reader.&lt;/p&gt;
&lt;p&gt;This is because there is no synchronisation whatsoever between the
writer and the reader.&lt;/p&gt;
&lt;p&gt;Fix this by writing data_avail with smp_store_release and reading
it with smp_load_acquire when we first enter read.  The subsequent
reads are safe because they&amp;#39;re either protected by the first load
acquire, or by the completion mechanism.&lt;/p&gt;
&lt;p&gt;Also remove the redundant zeroing of data_idx in random_recv_done
(data_idx must already be zero at this point) and data_avail in
request_entropy (ditto).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-g2vv-m9x5-457j</guid>
    </item>
    <item>
      <title>OESA-2026-1231 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-1231</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;scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()&lt;/p&gt;
&lt;p&gt;When executing SMP task failed, the smp_execute_task_sg() calls del_timer()
to delete &amp;amp;quot;slow_task-&amp;amp;gt;timer&amp;amp;quot;. However, if the timer handler
sas_task_internal_timedout() is running, the del_timer() in
smp_execute_task_sg() will not stop it and a UAF will happen. The process
is shown below:&lt;/p&gt;
&lt;p&gt;(thread 1)               |        (thread 2)
smp_execute_task_sg()          | sas_task_internal_timedout()
 ...                           |
 del_timer()                   |
 ...                           |  ...
 sas_free_task(task)           |
  kfree(task-&amp;amp;gt;slow_task) //FREE|
                               |  task-&amp;amp;gt;slow_task-&amp;amp;gt;... //USE&lt;/p&gt;
&lt;p&gt;Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure
the timer handler have finished before the &amp;amp;quot;task-&amp;amp;gt;slow_task&amp;amp;quot; is
deallocated.(CVE-2022-50422)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ppp: associate skb with a device at tx&lt;/p&gt;
&lt;p&gt;Syzkaller triggered flow dissector warning with the following:&lt;/p&gt;
&lt;p&gt;r0 = openat$ppp(0xffffffffffffff9c, &amp;amp;amp;(0x7f0000000000), 0xc0802, 0x0)
ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &amp;amp;amp;(0x7f00000000c0))
ioctl$PPPIOCSACTIVE(r0, 0x40107446, &amp;amp;amp;(0x7f0000000240)={0x2, &amp;amp;amp;(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})
pwritev(r0, &amp;amp;amp;(0x7f0000…&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;scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()&lt;/p&gt;
&lt;p&gt;When executing SMP task failed, the smp_execute_task_sg() calls del_timer()
to delete &amp;amp;quot;slow_task-&amp;amp;gt;timer&amp;amp;quot;. However, if the timer handler
sas_task_internal_timedout() is running, the del_timer() in
smp_execute_task_sg() will not stop it and a UAF will happen. The process
is shown below:&lt;/p&gt;
&lt;p&gt;(thread 1)               |        (thread 2)
smp_execute_task_sg()          | sas_task_internal_timedout()
 ...                           |
 del_timer()                   |
 ...                           |  ...
 sas_free_task(task)           |
  kfree(task-&amp;amp;gt;slow_task) //FREE|
                               |  task-&amp;amp;gt;slow_task-&amp;amp;gt;... //USE&lt;/p&gt;
&lt;p&gt;Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure
the timer handler have finished before the &amp;amp;quot;task-&amp;amp;gt;slow_task&amp;amp;quot; is
deallocated.(CVE-2022-50422)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ppp: associate skb with a device at tx&lt;/p&gt;
&lt;p&gt;Syzkaller triggered flow dissector warning with the following:&lt;/p&gt;
&lt;p&gt;r0 = openat$ppp(0xffffffffffffff9c, &amp;amp;amp;(0x7f0000000000), 0xc0802, 0x0)
ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &amp;amp;amp;(0x7f00000000c0))
ioctl$PPPIOCSACTIVE(r0, 0x40107446, &amp;amp;amp;(0x7f0000000240)={0x2, &amp;amp;amp;(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})
pwritev(r0, &amp;amp;amp;(0x7f0000…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-1231</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0263-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:0263-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-2026:0263-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53998</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53998</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: hwrng: virtio - Fix race on data_avail and actual data The virtio rng device kicks off a new entropy request whenever the data available reaches zero.  When a new request occurs at the end of a read operation, that is, when the result of that request is only needed by the next reader, then there is a race between the writing of the new data and the next reader. This is because there is no synchronisation whatsoever between the writer and the reader. Fix this by writing data_avail with smp_store_release and reading it with smp_load_acquire when we first enter read.  The subsequent reads are safe because they&amp;#39;re either protected by the first load acquire, or by the completion mechanism. Also remove the redundant zeroing of data_idx in random_recv_done (data_idx must already be zero at this point) and data_avail in request_entropy (ditto).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: hwrng: virtio - Fix race on data_avail and actual data The virtio rng device kicks off a new entropy request whenever the data available reaches zero.  When a new request occurs at the end of a read operation, that is, when the result of that request is only needed by the next reader, then there is a race between the writing of the new data and the next reader. This is because there is no synchronisation whatsoever between the writer and the reader. Fix this by writing data_avail with smp_store_release and reading it with smp_load_acquire when we first enter read.  The subsequent reads are safe because they&amp;#39;re either protected by the first load acquire, or by the completion mechanism. Also remove the redundant zeroing of data_idx in random_recv_done (data_idx must already be zero at this point) and data_avail in request_entropy (ditto).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53998</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2920 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2920</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2920</guid>
    </item>
  </channel>
</rss>
