In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
A recent DRM series purporting to simplify support for "transparent
bridges" and handling of probe deferrals ironically exposed a
use-after-free issue on pmic_glink_altmode probe deferral.
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.
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.
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.
When the display controller is later initialised, this triggers a
use-after-free when attaching the bridges:
dp -> aux -> dp-hpd (freed)
which may, for example, result in the freed bridge failing to attach:
[drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16
or a NULL-pointer dereference:
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]
msm_dp_modeset_init+0x28/0xc4 [msm]
The DRM bridge implementation is clearly fragile and implicitly built on
the assumption that bridges may never go away. In this case, the fix is
to move the bridge registration in the pmic_glink_altmode driver to
after all resources have been looked up.
Incidentally, with the new dp-hpd bridge implementation, which registers
child devices, this is also a requirement due to a long-standing issue
in driver core that can otherwise lead to a probe deferral loop (see
commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).
[DB: slightly fixed commit message by adding the word 'commit']
Security readout for executives and security teams
Plain-English summary
A Linux kernel race can leave the Qualcomm display subsystem using an object after it has been freed. On affected hardware, this may cause display initialization failures or a kernel NULL-pointer crash during boot. The supplied assessment rates it high at CVSS 7.0, although practical exploitation evidence is absent.
Executive priority
Prioritize validation on Qualcomm-based Linux endpoints, especially operationally important systems or those showing boot instability. Patch through supported distribution channels once applicability is confirmed. Broad emergency action across unrelated Linux fleets is not supported by the supplied evidence.
Technical view
During pmic_glink_altmode probe deferral, the dp-hpd DRM bridge may be deregistered after another driver stores its non-reference-counted pointer. Later bridge attachment can dereference freed memory. The kernel fix registers the bridge only after all required resources are acquired, closing the race window.
Likely exposure
Exposure appears limited to Linux systems using the Qualcomm pmic_glink_altmode and associated DRM display bridge path; Lenovo ThinkPad X13s is a documented example. The supplied version data lists Linux 6.3, 6.6.23, 6.7.11, and 6.8 but does not clearly define complete affected or fixed ranges.
Exploitation context
The CVSS vector describes local access, low privileges, high complexity, and potential confidentiality, integrity, and availability impact. Supplied evidence documents boot-time display failures and NULL-pointer dereferences, not successful malicious exploitation. The CVE is not identified as CISA KEV in the bundle.
Researcher notes
The trigger is a probe-deferral race involving bridge lifetime and an uncounted pointer. Observed consequences include attachment failure and kernel NULL dereference. The sources describe a corrective registration-order change, but provide no proof of exploitation, complete affected-version boundaries, or architecture-wide applicability beyond this driver path.
Mitigation direction
Identify systems using Qualcomm pmic_glink_altmode and the affected DRM bridge path.
Obtain a vendor-supported kernel containing the referenced upstream or stable fix.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-26909 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.