<?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://vulnerability.circl.lu</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>Tue, 29 Sep 2026 20:48:55 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-38600 — ALSA: Fix deadlocks with kctl removals at disconnection</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-38600</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: Fix deadlocks with kctl removals at disconnection&lt;/p&gt;
&lt;p&gt;In snd_card_disconnect(), we set card-&amp;gt;shutdown flag at the beginning,
call callbacks and do sync for card-&amp;gt;power_ref_sleep waiters at the
end.  The callback may delete a kctl element, and this can lead to a
deadlock when the device was in the suspended state.  Namely:&lt;/p&gt;
&lt;p&gt;* A process waits for the power up at snd_power_ref_and_wait() in
  snd_ctl_info() or read/write() inside card-&amp;gt;controls_rwsem.&lt;/p&gt;
&lt;p&gt;* The system gets disconnected meanwhile, and the driver tries to
  delete a kctl via snd_ctl_remove*(); it tries to take
  card-&amp;gt;controls_rwsem again, but this is already locked by the
  above.  Since the sleeper isn&amp;#39;t woken up, this deadlocks.&lt;/p&gt;
&lt;p&gt;An easy fix is to wake up sleepers before processing the driver
disconnect callbacks but right after setting the card-&amp;gt;shutdown flag.
Then all sleepers will abort immediately, and the code flows again.&lt;/p&gt;
&lt;p&gt;So, basically this patch moves the wait_event() call at the right
timing.  While we&amp;#39;re at it, just to be sure, call wait_event_all()
instead of wait_event(), although we don&amp;#39;t use exclusive events on
this queue for now.&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: Fix deadlocks with kctl removals at disconnection&lt;/p&gt;
&lt;p&gt;In snd_card_disconnect(), we set card-&amp;gt;shutdown flag at the beginning,
call callbacks and do sync for card-&amp;gt;power_ref_sleep waiters at the
end.  The callback may delete a kctl element, and this can lead to a
deadlock when the device was in the suspended state.  Namely:&lt;/p&gt;
&lt;p&gt;* A process waits for the power up at snd_power_ref_and_wait() in
  snd_ctl_info() or read/write() inside card-&amp;gt;controls_rwsem.&lt;/p&gt;
&lt;p&gt;* The system gets disconnected meanwhile, and the driver tries to
  delete a kctl via snd_ctl_remove*(); it tries to take
  card-&amp;gt;controls_rwsem again, but this is already locked by the
  above.  Since the sleeper isn&amp;#39;t woken up, this deadlocks.&lt;/p&gt;
&lt;p&gt;An easy fix is to wake up sleepers before processing the driver
disconnect callbacks but right after setting the card-&amp;gt;shutdown flag.
Then all sleepers will abort immediately, and the code flows again.&lt;/p&gt;
&lt;p&gt;So, basically this patch moves the wait_event() call at the right
timing.  While we&amp;#39;re at it, just to be sure, call wait_event_all()
instead of wait_event(), although we don&amp;#39;t use exclusive events on
this queue for now.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-38600</guid>
    </item>
  </channel>
</rss>
