<?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 23:04:31 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-03747</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-03747</link>
      <description>bdu:2024-03747</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-03747</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-26654</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-26654</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, 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:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-26654</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0329 — 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-0329</link>
      <description>certfr-2024-avi-0329</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0329</guid>
    </item>
    <item>
      <title>EUVD-2026-345479</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345479</link>
      <description>EUVD-2026-345479</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345479</guid>
    </item>
    <item>
      <title>fkie_cve-2024-26654</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-26654</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs&lt;/p&gt;
&lt;p&gt;The dreamcastcard-&amp;gt;timer could schedule the spu_dma_work and the
spu_dma_work could also arm the dreamcastcard-&amp;gt;timer.&lt;/p&gt;
&lt;p&gt;When the snd_pcm_substream is closing, the aica_channel will be
deallocated. But it could still be dereferenced in the worker
thread. The reason is that del_timer() will return directly
regardless of whether the timer handler is running or not and
the worker could be rescheduled in the timer handler. As a result,
the UAF bug will happen. The racy situation is shown below:&lt;/p&gt;
&lt;p&gt;(Thread 1)                 |      (Thread 2)
snd_aicapcm_pcm_close()          |
 ...                             |  run_spu_dma() //worker
                                 |    mod_timer()
  flush_work()                   |
  del_timer()                    |  aica_period_elapsed() //timer
  kfree(dreamcastcard-&amp;gt;channel)  |    schedule_work()
                                 |  run_spu_dma() //worker
  ...                            |    dreamcastcard-&amp;gt;channel-&amp;gt; //USE&lt;/p&gt;
&lt;p&gt;In order to mitigate this bug and other possible corner cases,
call mod_timer() conditionally in run_spu_dma(), then implement
PCM sync_stop op to cancel both the timer and worker. The sync_stop
op will be called from PCM core appropriately when needed.&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;ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs&lt;/p&gt;
&lt;p&gt;The dreamcastcard-&amp;gt;timer could schedule the spu_dma_work and the
spu_dma_work could also arm the dreamcastcard-&amp;gt;timer.&lt;/p&gt;
&lt;p&gt;When the snd_pcm_substream is closing, the aica_channel will be
deallocated. But it could still be dereferenced in the worker
thread. The reason is that del_timer() will return directly
regardless of whether the timer handler is running or not and
the worker could be rescheduled in the timer handler. As a result,
the UAF bug will happen. The racy situation is shown below:&lt;/p&gt;
&lt;p&gt;(Thread 1)                 |      (Thread 2)
snd_aicapcm_pcm_close()          |
 ...                             |  run_spu_dma() //worker
                                 |    mod_timer()
  flush_work()                   |
  del_timer()                    |  aica_period_elapsed() //timer
  kfree(dreamcastcard-&amp;gt;channel)  |    schedule_work()
                                 |  run_spu_dma() //worker
  ...                            |    dreamcastcard-&amp;gt;channel-&amp;gt; //USE&lt;/p&gt;
&lt;p&gt;In order to mitigate this bug and other possible corner cases,
call mod_timer() conditionally in run_spu_dma(), then implement
PCM sync_stop op to cancel both the timer and worker. The sync_stop
op will be called from PCM core appropriately when needed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-26654</guid>
    </item>
    <item>
      <title>GHSA-pgc5-vrj2-c9w5</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-pgc5-vrj2-c9w5</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs&lt;/p&gt;
&lt;p&gt;The dreamcastcard-&amp;gt;timer could schedule the spu_dma_work and the
spu_dma_work could also arm the dreamcastcard-&amp;gt;timer.&lt;/p&gt;
&lt;p&gt;When the snd_pcm_substream is closing, the aica_channel will be
deallocated. But it could still be dereferenced in the worker
thread. The reason is that del_timer() will return directly
regardless of whether the timer handler is running or not and
the worker could be rescheduled in the timer handler. As a result,
the UAF bug will happen. The racy situation is shown below:&lt;/p&gt;
&lt;p&gt;(Thread 1)                 |      (Thread 2)
snd_aicapcm_pcm_close()          |
 ...                             |  run_spu_dma() //worker
                                 |    mod_timer()
  flush_work()                   |
  del_timer()                    |  aica_period_elapsed() //timer
  kfree(dreamcastcard-&amp;gt;channel)  |    schedule_work()
                                 |  run_spu_dma() //worker
  ...                            |    dreamcastcard-&amp;gt;channel-&amp;gt; //USE&lt;/p&gt;
&lt;p&gt;In order to mitigate this bug and other possible corner cases,
call mod_timer() conditionally in run_spu_dma(), then implement
PCM sync_stop op to cancel both the timer and worker. The sync_stop
op will be called from PCM core appropriately when needed.&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;ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs&lt;/p&gt;
&lt;p&gt;The dreamcastcard-&amp;gt;timer could schedule the spu_dma_work and the
spu_dma_work could also arm the dreamcastcard-&amp;gt;timer.&lt;/p&gt;
&lt;p&gt;When the snd_pcm_substream is closing, the aica_channel will be
deallocated. But it could still be dereferenced in the worker
thread. The reason is that del_timer() will return directly
regardless of whether the timer handler is running or not and
the worker could be rescheduled in the timer handler. As a result,
the UAF bug will happen. The racy situation is shown below:&lt;/p&gt;
&lt;p&gt;(Thread 1)                 |      (Thread 2)
snd_aicapcm_pcm_close()          |
 ...                             |  run_spu_dma() //worker
                                 |    mod_timer()
  flush_work()                   |
  del_timer()                    |  aica_period_elapsed() //timer
  kfree(dreamcastcard-&amp;gt;channel)  |    schedule_work()
                                 |  run_spu_dma() //worker
  ...                            |    dreamcastcard-&amp;gt;channel-&amp;gt; //USE&lt;/p&gt;
&lt;p&gt;In order to mitigate this bug and other possible corner cases,
call mod_timer() conditionally in run_spu_dma(), then implement
PCM sync_stop op to cancel both the timer and worker. The sync_stop
op will be called from PCM core appropriately when needed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-pgc5-vrj2-c9w5</guid>
    </item>
    <item>
      <title>gsd-2024-26654</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2024-26654</link>
      <description>gsd-2024-26654</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2024-26654</guid>
    </item>
    <item>
      <title>OESA-2024-1496 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1496</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;
vt: fix memory overlapping when deleting chars in the buffer&#13;
&#13;
A memory overlapping copy occurs when deleting a long line. This memory
overlapping copy can cause data corruption when scr_memcpyw is optimized
to memcpy because memcpy does not ensure its behavior if the destination
buffer overlaps with the source buffer. The line buffer is not always
broken, because the memcpy utilizes the hardware acceleration, whose
result is not deterministic.&#13;
&#13;
Fix this problem by using replacing the scr_memcpyw with scr_memmovew.(CVE-2022-48627)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
crypto: qcom-rng - ensure buffer for generate is completely filled&#13;
&#13;
The generate function in struct rng_alg expects that the destination
buffer is completely filled if the function returns 0. qcom_rng_read()
can run into a situation where the buffer is partially filled with
randomness and the remaining part of the buffer is zeroed since
qcom_rng_generate() doesn&amp;amp;apos;t check the return value. This issue can
be reproduced by running the following from libkcapi:&#13;
&#13;
    kcapi-rng -b 9000000 &amp;amp;gt; OUTFILE&#13;
&#13;
The generated OUTFILE will have three huge sections that contain all
zeros, and this is caused by the code where the test
&amp;amp;apos;val &amp;amp;amp; PRNG_STATUS_DATA_AVAIL&amp;amp;apos; fails.&#13;
&#13;
Let&amp;amp;apos;s fix this issue by ensuring that qcom_rn…&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;
vt: fix memory overlapping when deleting chars in the buffer&#13;
&#13;
A memory overlapping copy occurs when deleting a long line. This memory
overlapping copy can cause data corruption when scr_memcpyw is optimized
to memcpy because memcpy does not ensure its behavior if the destination
buffer overlaps with the source buffer. The line buffer is not always
broken, because the memcpy utilizes the hardware acceleration, whose
result is not deterministic.&#13;
&#13;
Fix this problem by using replacing the scr_memcpyw with scr_memmovew.(CVE-2022-48627)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
crypto: qcom-rng - ensure buffer for generate is completely filled&#13;
&#13;
The generate function in struct rng_alg expects that the destination
buffer is completely filled if the function returns 0. qcom_rng_read()
can run into a situation where the buffer is partially filled with
randomness and the remaining part of the buffer is zeroed since
qcom_rng_generate() doesn&amp;amp;apos;t check the return value. This issue can
be reproduced by running the following from libkcapi:&#13;
&#13;
    kcapi-rng -b 9000000 &amp;amp;gt; OUTFILE&#13;
&#13;
The generated OUTFILE will have three huge sections that contain all
zeros, and this is caused by the code where the test
&amp;amp;apos;val &amp;amp;amp; PRNG_STATUS_DATA_AVAIL&amp;amp;apos; fails.&#13;
&#13;
Let&amp;amp;apos;s fix this issue by ensuring that qcom_rn…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1496</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:1466-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:1466-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:1466-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-26654</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26654</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, 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 171 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard-&amp;gt;timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard-&amp;gt;timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below:       (Thread 1)                 |      (Thread 2) snd_aicapcm_pcm_close()          |  ...                             |  run_spu_dma() //worker                                  |    mod_timer()   flush_work()                   |   del_timer()                    |  aica_period_elapsed() //timer   kfree(dreamcastcard-&amp;gt;channel)  |    schedule_work()                                  |  run_spu_dma() //worker   ...                            |    dreamcastcard-&amp;gt;channel-&amp;gt; //USE In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, 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 171 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard-&amp;gt;timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard-&amp;gt;timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below:       (Thread 1)                 |      (Thread 2) snd_aicapcm_pcm_close()          |  ...                             |  run_spu_dma() //worker                                  |    mod_timer()   flush_work()                   |   del_timer()                    |  aica_period_elapsed() //timer   kfree(dreamcastcard-&amp;gt;channel)  |    schedule_work()                                  |  run_spu_dma() //worker   ...                            |    dreamcastcard-&amp;gt;channel-&amp;gt; //USE In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26654</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>
