CVE-2024-26909

Source
https://nvd.nist.gov/vuln/detail/CVE-2024-26909
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-26909.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2024-26909
Downstream
Related
Published
2024-04-17T10:27:55Z
Modified
2025-10-09T06:23:49.806578Z
Summary
soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
Details

In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: pmicglinkaltmode: 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 pmicglinkaltmode 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 pmicglinkaltmode 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']

References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
080b4e24852b1d5b66929f69344e6c3eeb963941
Fixed
2bbd65c6ca567ed8dbbfc4fb945f57ce64bef342
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
080b4e24852b1d5b66929f69344e6c3eeb963941
Fixed
ef45aa2841e15b649e5417fe3d4de395fe462781
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
080b4e24852b1d5b66929f69344e6c3eeb963941
Fixed
b979f2d50a099f3402418d7ff5f26c3952fb08bb

Affected versions

v6.*

v6.2
v6.2-rc2
v6.2-rc3
v6.2-rc4
v6.2-rc5
v6.2-rc6
v6.2-rc7
v6.2-rc8
v6.3
v6.3-rc1
v6.3-rc2
v6.3-rc3
v6.3-rc4
v6.3-rc5
v6.3-rc6
v6.3-rc7
v6.4
v6.4-rc1
v6.4-rc2
v6.4-rc3
v6.4-rc4
v6.4-rc5
v6.4-rc6
v6.4-rc7
v6.5
v6.5-rc1
v6.5-rc2
v6.5-rc3
v6.5-rc4
v6.5-rc5
v6.5-rc6
v6.5-rc7
v6.6
v6.6-rc1
v6.6-rc2
v6.6-rc3
v6.6-rc4
v6.6-rc5
v6.6-rc6
v6.6-rc7
v6.6.1
v6.6.10
v6.6.11
v6.6.12
v6.6.13
v6.6.14
v6.6.15
v6.6.16
v6.6.17
v6.6.18
v6.6.19
v6.6.2
v6.6.20
v6.6.21
v6.6.22
v6.6.3
v6.6.4
v6.6.5
v6.6.6
v6.6.7
v6.6.8
v6.6.9
v6.7
v6.7-rc1
v6.7-rc2
v6.7-rc3
v6.7-rc4
v6.7-rc5
v6.7-rc6
v6.7-rc7
v6.7-rc8
v6.7.1
v6.7.10
v6.7.2
v6.7.3
v6.7.4
v6.7.5
v6.7.6
v6.7.7
v6.7.8
v6.7.9
v6.8-rc1

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.3.0
Fixed
6.6.23
Type
ECOSYSTEM
Events
Introduced
6.7.0
Fixed
6.7.11