CVE-2024-26909

What it actually does

Use-after-free in the pmic_glink_altmode driver where a DRM dp-hpd bridge is registered before resources are acquired, allowing deregistration on probe deferral while aux/PHY drivers hold a non-refcounted pointer; later display initialization dereferences the freed object causing NULL pointer dereference or attach failure.

Why it matters to the business

Occasional boot-time display subsystem failures and kernel crashes on Qualcomm-based ARM systems such as Lenovo ThinkPad X13s, reducing device availability; low EPSS and no KEV status indicate limited active exploitation risk but still impacts kernel stability on affected hardware.

How an attack unfolds

An attacker with local access triggers probe deferral conditions in pmic_glink_altmode to create a race where the dp-hpd bridge is freed while referenced; subsequent display controller initialization walks the bridge chain and dereferences the freed memory, potentially leading to denial of service or limited local kernel memory corruption.

How to fix it

Update to a Linux kernel containing commit 2bbd65c6ca567ed8dbbfc4fb945f57ce64bef342; rebuild and deploy the fixed kernel on all affected distributions and embedded devices.

How to confirm the fix worked

Confirm kernel git history contains 2bbd65c6ca567ed8dbbfc4fb945f57ce64bef342; boot affected hardware and verify absence of drm_bridge_attach errors or NULL dereferences for /soc@0/phy@88eb000 during msm_dp_modeset_init.

Typical attack path

1. Cause or wait for pmic_glink_altmode probe deferral
2. Allow aux bridge or PHY driver to store non-refcounted pointer to dp-hpd bridge
3. Trigger bridge deregistration on deferral freeing the object
4. Initialize display subsystem (dp_bridge_init) to walk and attach the now-freed bridge

How to detect it

Search kernel logs and dmesg for drm_bridge_attach failures mentioning dp-hpd or aux_bridge, NULL pointer dereferences at drm_bridge_attach+0x70, and msm_dp_modeset_init call traces during early boot.

What your security team should do

• Prioritize kernel updates on Qualcomm Snapdragon-based endpoints within standard patch windows
• Add boot-time drm and msm driver error monitoring to SIEM
• Test display initialization on representative hardware after updates