<?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 04:42:56 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-26909 — soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-26909</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;soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free&lt;/p&gt;
&lt;p&gt;A recent DRM series purporting to simplify support for &amp;#34;transparent
bridges&amp;#34; and handling of probe deferrals ironically exposed a
use-after-free issue on pmic_glink_altmode probe deferral.&lt;/p&gt;
&lt;p&gt;This has manifested itself as the display subsystem occasionally failing
to initialise and NULL-pointer dereferences during boot of machines like
the Lenovo ThinkPad X13s.&lt;/p&gt;
&lt;p&gt;Specifically, the dp-hpd bridge is currently registered before all
resources have been acquired which means that it can also be
deregistered on probe deferrals.&lt;/p&gt;
&lt;p&gt;In the meantime there is a race window where the new aux bridge driver
(or PHY driver previously) may have looked up the dp-hpd bridge and
stored a (non-reference-counted) pointer to the bridge which is about to
be deallocated.&lt;/p&gt;
&lt;p&gt;When the display controller is later initialised, this triggers a
use-after-free when attaching the bridges:&lt;/p&gt;
&lt;p&gt;dp -&amp;gt; aux -&amp;gt; dp-hpd (freed)&lt;/p&gt;
&lt;p&gt;which may, for example, result in the freed bridge failing to attach:&lt;/p&gt;
&lt;p&gt;[drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16&lt;/p&gt;
&lt;p&gt;or a NULL-pointer dereference:&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
	...
	Call trace:
	  drm_bridge_attach+0x70/0x1a8 [drm]
	  drm_aux_bridge_attach+0x24/0x38 [aux_bridge]
	  drm_bridge_attach+0x80/0x1a8 [drm]
	  dp_bridge_init+0xa8/0x15c [msm]…&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;soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free&lt;/p&gt;
&lt;p&gt;A recent DRM series purporting to simplify support for &amp;#34;transparent
bridges&amp;#34; and handling of probe deferrals ironically exposed a
use-after-free issue on pmic_glink_altmode probe deferral.&lt;/p&gt;
&lt;p&gt;This has manifested itself as the display subsystem occasionally failing
to initialise and NULL-pointer dereferences during boot of machines like
the Lenovo ThinkPad X13s.&lt;/p&gt;
&lt;p&gt;Specifically, the dp-hpd bridge is currently registered before all
resources have been acquired which means that it can also be
deregistered on probe deferrals.&lt;/p&gt;
&lt;p&gt;In the meantime there is a race window where the new aux bridge driver
(or PHY driver previously) may have looked up the dp-hpd bridge and
stored a (non-reference-counted) pointer to the bridge which is about to
be deallocated.&lt;/p&gt;
&lt;p&gt;When the display controller is later initialised, this triggers a
use-after-free when attaching the bridges:&lt;/p&gt;
&lt;p&gt;dp -&amp;gt; aux -&amp;gt; dp-hpd (freed)&lt;/p&gt;
&lt;p&gt;which may, for example, result in the freed bridge failing to attach:&lt;/p&gt;
&lt;p&gt;[drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16&lt;/p&gt;
&lt;p&gt;or a NULL-pointer dereference:&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
	...
	Call trace:
	  drm_bridge_attach+0x70/0x1a8 [drm]
	  drm_aux_bridge_attach+0x24/0x38 [aux_bridge]
	  drm_bridge_attach+0x80/0x1a8 [drm]
	  dp_bridge_init+0xa8/0x15c [msm]…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-26909</guid>
    </item>
  </channel>
</rss>
