<?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>Fri, 02 Oct 2026 19:35:53 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74261</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-74261</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-2026-74261</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1231 — 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-1231</link>
      <description>certfr-2026-avi-1231</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1231</guid>
    </item>
    <item>
      <title>EUVD-2026-353798</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353798</link>
      <description>EUVD-2026-353798</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353798</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74261</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74261</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: seq: avoid stale FIFO cells during resize&lt;/p&gt;
&lt;p&gt;snd_seq_fifo_resize() still needs to publish the replacement pool
before it waits for FIFO users. A blocking snd_seq_read() holds
f-&amp;gt;use_lock while it sleeps, so concurrent senders must be able to
queue to the new pool and wake that reader instead of failing against a
closing old pool.&lt;/p&gt;
&lt;p&gt;However, snd_seq_fifo_event_in() duplicates an event before it takes
f-&amp;gt;lock, and snd_seq_read() can dequeue a cell and later call
snd_seq_fifo_cell_putback() if copy_to_user() or
snd_seq_expand_var_event() fails. If resize swaps f-&amp;gt;pool and detaches
oldhead in between, either path can relink an old-pool cell after the
snapshot. That stale cell sits outside the drained oldhead list, keeps
oldpool-&amp;gt;counter elevated, and can leave snd_seq_pool_delete() waiting
for the retired pool to drain.&lt;/p&gt;
&lt;p&gt;Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(),
but reject stale cells before any FIFO relink. Revalidate event-in cells
under f-&amp;gt;lock and retry them against the published replacement pool, and
free stale putback cells instead of linking them back into the FIFO.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the
order within that path:&lt;/p&gt;
&lt;p&gt;resize path:                    relink path:
1. Allocate newpool.             1. Take f-&amp;gt;use_lock.
2. Swap f-&amp;gt;pool to newpool and   2. Duplicate or dequeue an old-pool
   detach oldhead.                  cell before old…&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: seq: avoid stale FIFO cells during resize&lt;/p&gt;
&lt;p&gt;snd_seq_fifo_resize() still needs to publish the replacement pool
before it waits for FIFO users. A blocking snd_seq_read() holds
f-&amp;gt;use_lock while it sleeps, so concurrent senders must be able to
queue to the new pool and wake that reader instead of failing against a
closing old pool.&lt;/p&gt;
&lt;p&gt;However, snd_seq_fifo_event_in() duplicates an event before it takes
f-&amp;gt;lock, and snd_seq_read() can dequeue a cell and later call
snd_seq_fifo_cell_putback() if copy_to_user() or
snd_seq_expand_var_event() fails. If resize swaps f-&amp;gt;pool and detaches
oldhead in between, either path can relink an old-pool cell after the
snapshot. That stale cell sits outside the drained oldhead list, keeps
oldpool-&amp;gt;counter elevated, and can leave snd_seq_pool_delete() waiting
for the retired pool to drain.&lt;/p&gt;
&lt;p&gt;Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(),
but reject stale cells before any FIFO relink. Revalidate event-in cells
under f-&amp;gt;lock and retry them against the published replacement pool, and
free stale putback cells instead of linking them back into the FIFO.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the
order within that path:&lt;/p&gt;
&lt;p&gt;resize path:                    relink path:
1. Allocate newpool.             1. Take f-&amp;gt;use_lock.
2. Swap f-&amp;gt;pool to newpool and   2. Duplicate or dequeue an old-pool
   detach oldhead.                  cell before old…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-74261</guid>
    </item>
    <item>
      <title>GHSA-7ggr-r5fp-3744</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7ggr-r5fp-3744</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: seq: avoid stale FIFO cells during resize&lt;/p&gt;
&lt;p&gt;snd_seq_fifo_resize() still needs to publish the replacement pool
before it waits for FIFO users. A blocking snd_seq_read() holds
f-&amp;gt;use_lock while it sleeps, so concurrent senders must be able to
queue to the new pool and wake that reader instead of failing against a
closing old pool.&lt;/p&gt;
&lt;p&gt;However, snd_seq_fifo_event_in() duplicates an event before it takes
f-&amp;gt;lock, and snd_seq_read() can dequeue a cell and later call
snd_seq_fifo_cell_putback() if copy_to_user() or
snd_seq_expand_var_event() fails. If resize swaps f-&amp;gt;pool and detaches
oldhead in between, either path can relink an old-pool cell after the
snapshot. That stale cell sits outside the drained oldhead list, keeps
oldpool-&amp;gt;counter elevated, and can leave snd_seq_pool_delete() waiting
for the retired pool to drain.&lt;/p&gt;
&lt;p&gt;Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(),
but reject stale cells before any FIFO relink. Revalidate event-in cells
under f-&amp;gt;lock and retry them against the published replacement pool, and
free stale putback cells instead of linking them back into the FIFO.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the
order within that path:&lt;/p&gt;
&lt;p&gt;resize path:                    relink path:
1. Allocate newpool.             1. Take f-&amp;gt;use_lock.
2. Swap f-&amp;gt;pool to newpool and   2. Duplicate or dequeue an old-pool
   detach oldhead.                  cell before old…&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: seq: avoid stale FIFO cells during resize&lt;/p&gt;
&lt;p&gt;snd_seq_fifo_resize() still needs to publish the replacement pool
before it waits for FIFO users. A blocking snd_seq_read() holds
f-&amp;gt;use_lock while it sleeps, so concurrent senders must be able to
queue to the new pool and wake that reader instead of failing against a
closing old pool.&lt;/p&gt;
&lt;p&gt;However, snd_seq_fifo_event_in() duplicates an event before it takes
f-&amp;gt;lock, and snd_seq_read() can dequeue a cell and later call
snd_seq_fifo_cell_putback() if copy_to_user() or
snd_seq_expand_var_event() fails. If resize swaps f-&amp;gt;pool and detaches
oldhead in between, either path can relink an old-pool cell after the
snapshot. That stale cell sits outside the drained oldhead list, keeps
oldpool-&amp;gt;counter elevated, and can leave snd_seq_pool_delete() waiting
for the retired pool to drain.&lt;/p&gt;
&lt;p&gt;Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(),
but reject stale cells before any FIFO relink. Revalidate event-in cells
under f-&amp;gt;lock and retry them against the published replacement pool, and
free stale putback cells instead of linking them back into the FIFO.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the
order within that path:&lt;/p&gt;
&lt;p&gt;resize path:                    relink path:
1. Allocate newpool.             1. Take f-&amp;gt;use_lock.
2. Swap f-&amp;gt;pool to newpool and   2. Duplicate or dequeue an old-pool
   detach oldhead.                  cell before old…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7ggr-r5fp-3744</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-74261 — ALSA: seq: avoid stale FIFO cells during resize</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-74261</link>
      <description>msrc_CVE-2026-74261</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-74261</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-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/opensuse-su-2026:21910-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23881-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23881-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:23881-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74261</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74261</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: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, Ubuntu:16.04:LTS: linux-hwe-edge and 245 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: avoid stale FIFO cells during resize snd_seq_fifo_resize() still needs to publish the replacement pool before it waits for FIFO users. A blocking snd_seq_read() holds f-&amp;gt;use_lock while it sleeps, so concurrent senders must be able to queue to the new pool and wake that reader instead of failing against a closing old pool. However, snd_seq_fifo_event_in() duplicates an event before it takes f-&amp;gt;lock, and snd_seq_read() can dequeue a cell and later call snd_seq_fifo_cell_putback() if copy_to_user() or snd_seq_expand_var_event() fails. If resize swaps f-&amp;gt;pool and detaches oldhead in between, either path can relink an old-pool cell after the snapshot. That stale cell sits outside the drained oldhead list, keeps oldpool-&amp;gt;counter elevated, and can leave snd_seq_pool_delete() waiting for the retired pool to drain. Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(), but reject stale cells before any FIFO relink. Revalidate event-in cells under f-&amp;gt;lock and retry them against the published replacement pool, and free stale putback cells instead of linking them back into the FIFO. The buggy scenario involves two paths, with each column showing the order within that path: resize path:                    relink path: 1. Allocate newpool.             1. Take f-&amp;gt;use_lock. 2. Swap f-&amp;gt;pool to newpool and   2. Duplicate or dequeue an old-pool    detach oldhead.                  cell before oldpool c…&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: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, Ubuntu:16.04:LTS: linux-hwe-edge and 245 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: avoid stale FIFO cells during resize snd_seq_fifo_resize() still needs to publish the replacement pool before it waits for FIFO users. A blocking snd_seq_read() holds f-&amp;gt;use_lock while it sleeps, so concurrent senders must be able to queue to the new pool and wake that reader instead of failing against a closing old pool. However, snd_seq_fifo_event_in() duplicates an event before it takes f-&amp;gt;lock, and snd_seq_read() can dequeue a cell and later call snd_seq_fifo_cell_putback() if copy_to_user() or snd_seq_expand_var_event() fails. If resize swaps f-&amp;gt;pool and detaches oldhead in between, either path can relink an old-pool cell after the snapshot. That stale cell sits outside the drained oldhead list, keeps oldpool-&amp;gt;counter elevated, and can leave snd_seq_pool_delete() waiting for the retired pool to drain. Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(), but reject stale cells before any FIFO relink. Revalidate event-in cells under f-&amp;gt;lock and retry them against the published replacement pool, and free stale putback cells instead of linking them back into the FIFO. The buggy scenario involves two paths, with each column showing the order within that path: resize path:                    relink path: 1. Allocate newpool.             1. Take f-&amp;gt;use_lock. 2. Swap f-&amp;gt;pool to newpool and   2. Duplicate or dequeue an old-pool    detach oldhead.                  cell before oldpool c…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74261</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen 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-2026-2852</guid>
    </item>
  </channel>
</rss>
