CVE-2024-26909
MediumIn 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']
CVSS 3.1 score
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness type
CWE-416CVE-2024-26909 is a Use After Free vulnerability
What is Use After Free?
The product references memory after it has been freed, which may cause it to crash, use unexpected values, or execute code. Learn more on MITRE CWE
References
The following references provide additional information about CVE-2024-26909 including vendor advisories, patch commits, exploit details, and third-party analysis. Links are sourced from the NIST NVD database.
-
PatchKernel patch commithttps://git.kernel.org/stable/c/2bbd65c6ca567ed8dbbfc4fb945f57ce64bef342
-
PatchKernel patch commithttps://git.kernel.org/stable/c/b979f2d50a099f3402418d7ff5f26c3952fb08bb
-
PatchKernel patch commithttps://git.kernel.org/stable/c/ef45aa2841e15b649e5417fe3d4de395fe462781
Frequently asked questions
-
What is CVE-2024-26909?
CVE-2024-26909 is a Medium severity Linux kernel vulnerability with a CVSS score of 5.5 out of 10 , classified as an Use After Free flaw (CWE-416) . CVE-2024-26909 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.
-
What is the CVSS score for CVE-2024-26909?
CVE-2024-26909 has a CVSS score of 5.5 out of 10, rated Medium severity (CVSS 3.1). The vector string is
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. -
Is there a patch available for CVE-2024-26909?
No patch is currently available for CVE-2024-26909. Monitor the NIST NVD and your Linux distribution's security advisories for updates.
-
Is CVE-2024-26909 actively exploited?
No — CVE-2024-26909 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.
-
What is Use After Free (CWE-416)?
The product references memory after it has been freed, which may cause it to crash, use unexpected values, or execute code. View CWE-416 on MITRE CWE →