CVE-2024-26909

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free<br /> <br /> A recent DRM series purporting to simplify support for "transparent<br /> bridges" and handling of probe deferrals ironically exposed a<br /> use-after-free issue on pmic_glink_altmode probe deferral.<br /> <br /> This has manifested itself as the display subsystem occasionally failing<br /> to initialise and NULL-pointer dereferences during boot of machines like<br /> the Lenovo ThinkPad X13s.<br /> <br /> Specifically, the dp-hpd bridge is currently registered before all<br /> resources have been acquired which means that it can also be<br /> deregistered on probe deferrals.<br /> <br /> In the meantime there is a race window where the new aux bridge driver<br /> (or PHY driver previously) may have looked up the dp-hpd bridge and<br /> stored a (non-reference-counted) pointer to the bridge which is about to<br /> be deallocated.<br /> <br /> When the display controller is later initialised, this triggers a<br /> use-after-free when attaching the bridges:<br /> <br /> dp -&gt; aux -&gt; dp-hpd (freed)<br /> <br /> which may, for example, result in the freed bridge failing to attach:<br /> <br /> [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16<br /> <br /> or a NULL-pointer dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> ...<br /> Call trace:<br /> drm_bridge_attach+0x70/0x1a8 [drm]<br /> drm_aux_bridge_attach+0x24/0x38 [aux_bridge]<br /> drm_bridge_attach+0x80/0x1a8 [drm]<br /> dp_bridge_init+0xa8/0x15c [msm]<br /> msm_dp_modeset_init+0x28/0xc4 [msm]<br /> <br /> The DRM bridge implementation is clearly fragile and implicitly built on<br /> the assumption that bridges may never go away. In this case, the fix is<br /> to move the bridge registration in the pmic_glink_altmode driver to<br /> after all resources have been looked up.<br /> <br /> Incidentally, with the new dp-hpd bridge implementation, which registers<br /> child devices, this is also a requirement due to a long-standing issue<br /> in driver core that can otherwise lead to a probe deferral loop (see<br /> commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).<br /> <br /> [DB: slightly fixed commit message by adding the word &amp;#39;commit&amp;#39;]