<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T18:34:24.221382+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-74261</id>
    <title>CVE-2026-74261 — ALSA: seq: avoid stale FIFO cells during resize</title>
    <updated>2026-10-02T18:34:24.223221+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>ALSA: seq: avoid stale FIFO cells during resize</p>
<p>snd_seq_fifo_resize() still needs to publish the replacement pool
before it waits for FIFO users. A blocking snd_seq_read() holds
f-&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.</p>
<p>However, snd_seq_fifo_event_in() duplicates an event before it takes
f-&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-&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-&gt;counter elevated, and can leave snd_seq_pool_delete() waiting
for the retired pool to drain.</p>
<p>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-&gt;lock and retry them against the published replacement pool, and
free stale putback cells instead of linking them back into the FIFO.</p>
<p>The buggy scenario involves two paths, with each column showing the
order within that path:</p>
<p>resize path:                    relink path:
1. Allocate newpool.             1. Take f-&gt;use_lock.
2. Swap f-&gt;pool to newpool and   2. Duplicate or dequeue an old-pool
   detach oldhead.                  cell before old…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-74261"/>
  </entry>
</feed>
