🛡️ AZL-40106 — kernel

⚪ Unknown ✅ No Known Exploit OSV
N/A
CVSS Score
0 Low4 Medium7 High9 Critical10

Description

CVE-2024-26909 affecting package kernel for versions less than 6.6.29.1-3

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']

How this vulnerability can be exploited

This issue can be reached with local access to the system, attack complexity is low, an attacker needs low-level privileges on the target. No user interaction is required. The scope is unchanged, so the impact stays within the vulnerable component. Rated impact: confidentiality none, integrity none, availability high.

Affected software

AZL-40106 is recorded against 1 package.

  • kernel (fixed in 6.6.29.1-3)

Timeline and source

Published on 17 April 2024 and last revised on 21 April 2026. No public exploit is currently recorded for this entry. Record sourced from OSV.

References

nvd.nist.gov (Web)

Details

Severity Unknown
CVSS Score N/A
CVSS Vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CWE N/A
Public Exploit ✅ No
Source OSV
Published 2024-04-17
Updated 2026-08-12
Modified 2026-04-21
Fix URL N/A

Affected Packages

Software From version Fixed in
kernel 6.6.29.1-3

Similar Threats

Free Vulnerability Check

Is your site affected by AZL-40106?

BotEraser helps you identify potentially vulnerable plugins and themes by checking your installation against AZL-40106 and other known CVE records.

Scan My Site Free →

No credit card required  ·  Results in minutes

ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.