CVE-2024-26909: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-26909

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

AI Analysis

Technical Summary

CVE-2024-26909 is a use-after-free vulnerability identified in the Linux kernel's Qualcomm PMIC Glink Altmode driver, specifically within the DRM (Direct Rendering Manager) bridge handling code. The vulnerability arises due to improper ordering of resource acquisition and bridge registration during the probe phase of the pmic_glink_altmode driver. The dp-hpd bridge is registered before all necessary resources are acquired, which can lead to its deregistration during probe deferrals. Meanwhile, other components such as the aux bridge driver may hold non-reference-counted pointers to this bridge. If the bridge is freed while these pointers exist, subsequent operations on these stale pointers cause use-after-free conditions. This manifests as failures in the display subsystem initialization or kernel NULL pointer dereferences during system boot, as observed on devices like the Lenovo ThinkPad X13s. The root cause is the fragile DRM bridge implementation that assumes bridges remain valid once registered. The fix involves deferring the bridge registration until after all resources are acquired, preventing premature deregistration and eliminating the race window. This vulnerability affects Linux kernel versions containing the vulnerable commit (identified by the hash 080b4e24852b1d5b66929f69344e6c3eeb963941) and impacts systems using Qualcomm PMIC Glink Altmode with DRM bridges, particularly those with dp-hpd bridge implementations. Although no known exploits are currently reported in the wild, the issue can cause system instability, boot failures, or kernel crashes, impacting device availability and reliability.

Potential Impact

For European organizations, this vulnerability primarily threatens devices running vulnerable Linux kernel versions with Qualcomm PMIC Glink Altmode drivers, such as certain laptops (e.g., Lenovo ThinkPad X13s) and embedded systems using similar hardware configurations. The impact includes potential denial of service due to kernel crashes or boot failures, which can disrupt business operations relying on affected hardware. In sectors like manufacturing, telecommunications, or critical infrastructure where embedded Linux devices are common, this could lead to operational downtime. Additionally, the instability could complicate system maintenance and updates. While this vulnerability does not directly expose confidentiality or integrity risks, the availability impact can be significant, especially in environments where uptime is critical. European organizations deploying Linux-based devices with Qualcomm hardware should be aware of this risk, as failure to patch could lead to unexpected system failures, affecting productivity and service continuity.

Mitigation Recommendations

1. Apply the official Linux kernel patches that address CVE-2024-26909 as soon as they are released and validated for your environment. 2. For organizations using custom or embedded Linux kernels, ensure that the pmic_glink_altmode driver is updated to register the DRM bridge only after all resources are acquired, following the upstream fix. 3. Conduct thorough testing of kernel updates in staging environments to verify that the display subsystem initializes correctly and no probe deferral loops occur. 4. Monitor system logs for drm_bridge_attach errors or kernel NULL pointer dereferences that may indicate the presence of this issue. 5. Where possible, implement kernel live patching to minimize downtime during remediation. 6. Maintain an inventory of devices using Qualcomm PMIC Glink Altmode drivers to prioritize patch deployment. 7. Engage with hardware vendors to confirm the availability of updated firmware or drivers that incorporate the fix. 8. Consider fallback or recovery mechanisms to restore device functionality in case of boot failures caused by this vulnerability.