<?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>Mon, 28 Sep 2026 17:52:17 +0000</lastBuildDate>
    <item>
      <title>CVE-2023-53275 — ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()</title>
      <link>https://db.gcve.eu/vuln/cve-2023-53275</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: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()&lt;/p&gt;
&lt;p&gt;The variable codec-&amp;gt;regmap is often protected by the lock
codec-&amp;gt;regmap_lock when is accessed. However, it is accessed without
holding the lock when is accessed in snd_hdac_regmap_sync():&lt;/p&gt;
&lt;p&gt;if (codec-&amp;gt;regmap)&lt;/p&gt;
&lt;p&gt;In my opinion, this may be a harmful race, because if codec-&amp;gt;regmap is
set to NULL right after the condition is checked, a null-pointer
dereference can occur in the called function regcache_sync():&lt;/p&gt;
&lt;p&gt;map-&amp;gt;lock(map-&amp;gt;lock_arg); --&amp;gt; Line 360 in drivers/base/regmap/regcache.c&lt;/p&gt;
&lt;p&gt;To fix this possible null-pointer dereference caused by data race, the
mutex_lock coverage is extended to protect the if statement as well as the
function call to regcache_sync().&lt;/p&gt;
&lt;p&gt;[ Note: the lack of the regmap_lock itself is harmless for the current
  codec driver implementations, as snd_hdac_regmap_sync() is only for
  PM runtime resume that is prohibited during the codec probe.
  But the change makes the whole code more consistent, so it&amp;#39;s merged
  as is -- tiwai ]&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: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()&lt;/p&gt;
&lt;p&gt;The variable codec-&amp;gt;regmap is often protected by the lock
codec-&amp;gt;regmap_lock when is accessed. However, it is accessed without
holding the lock when is accessed in snd_hdac_regmap_sync():&lt;/p&gt;
&lt;p&gt;if (codec-&amp;gt;regmap)&lt;/p&gt;
&lt;p&gt;In my opinion, this may be a harmful race, because if codec-&amp;gt;regmap is
set to NULL right after the condition is checked, a null-pointer
dereference can occur in the called function regcache_sync():&lt;/p&gt;
&lt;p&gt;map-&amp;gt;lock(map-&amp;gt;lock_arg); --&amp;gt; Line 360 in drivers/base/regmap/regcache.c&lt;/p&gt;
&lt;p&gt;To fix this possible null-pointer dereference caused by data race, the
mutex_lock coverage is extended to protect the if statement as well as the
function call to regcache_sync().&lt;/p&gt;
&lt;p&gt;[ Note: the lack of the regmap_lock itself is harmless for the current
  codec driver implementations, as snd_hdac_regmap_sync() is only for
  PM runtime resume that is prohibited during the codec probe.
  But the change makes the whole code more consistent, so it&amp;#39;s merged
  as is -- tiwai ]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2023-53275</guid>
    </item>
  </channel>
</rss>
