<?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://db.gcve.eu</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, 17 Oct 2026 21:07:47 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-98314 — ALSA: pcm: set timer-&gt;private_data before registering the PCM timer</title>
      <link>https://db.gcve.eu/vuln/cve-2026-98314</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: pcm: set timer-&amp;gt;private_data before registering the PCM timer&lt;/p&gt;
&lt;p&gt;snd_pcm_timer_init() calls snd_device_register() to link the new
struct snd_timer into the global timer list while it still carries
hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop),
and only afterwards sets timer-&amp;gt;private_data = substream.&lt;/p&gt;
&lt;p&gt;Once the timer is on the list under register_mutex, a concurrent
reader can already reach it through the same mutex and invoke these
callbacks. /proc/asound/timers does this via c_resolution(), and
snd_timer_open()+snd_timer_start() reach start()/stop() the same way.
All three dereference timer-&amp;gt;private_data, which for this brief
window is NULL, giving a NULL-pointer dereference:&lt;/p&gt;
&lt;p&gt;substream = timer-&amp;gt;private_data;
  return substream-&amp;gt;runtime ? ...   // substream is NULL&lt;/p&gt;
&lt;p&gt;Move the private_data/private_free assignment before
snd_device_register() so the timer is never visible on the list
without its private_data set. On the snd_device_register() failure
path, private_free() (snd_pcm_timer_free()) can now run, but it only
does substream-&amp;gt;timer = NULL, which is already NULL at that point
since substream-&amp;gt;timer is set to the new timer just once, after a
successful registration -- so the failure path stays safe.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: pcm: set timer-&amp;gt;private_data before registering the PCM timer&lt;/p&gt;
&lt;p&gt;snd_pcm_timer_init() calls snd_device_register() to link the new
struct snd_timer into the global timer list while it still carries
hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop),
and only afterwards sets timer-&amp;gt;private_data = substream.&lt;/p&gt;
&lt;p&gt;Once the timer is on the list under register_mutex, a concurrent
reader can already reach it through the same mutex and invoke these
callbacks. /proc/asound/timers does this via c_resolution(), and
snd_timer_open()+snd_timer_start() reach start()/stop() the same way.
All three dereference timer-&amp;gt;private_data, which for this brief
window is NULL, giving a NULL-pointer dereference:&lt;/p&gt;
&lt;p&gt;substream = timer-&amp;gt;private_data;
  return substream-&amp;gt;runtime ? ...   // substream is NULL&lt;/p&gt;
&lt;p&gt;Move the private_data/private_free assignment before
snd_device_register() so the timer is never visible on the list
without its private_data set. On the snd_device_register() failure
path, private_free() (snd_pcm_timer_free()) can now run, but it only
does substream-&amp;gt;timer = NULL, which is already NULL at that point
since substream-&amp;gt;timer is set to the new timer just once, after a
successful registration -- so the failure path stays safe.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-98314</guid>
    </item>
  </channel>
</rss>
