发布时间: 2024年5月27日
修改时间: 2024年6月13日
In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pmic_glink_altmode: fix drm bridge use-after-freeA recent DRM series purporting to simplify support for transparentbridges and handling of probe deferrals ironically exposed ause-after-free issue on pmic_glink_altmode probe deferral.This has manifested itself as the display subsystem occasionally failingto initialise and NULL-pointer dereferences during boot of machines likethe Lenovo ThinkPad X13s.Specifically, the dp-hpd bridge is currently registered before allresources have been acquired which means that it can also bederegistered 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 andstored a (non-reference-counted) pointer to the bridge which is about tobe deallocated.When the display controller is later initialised, this triggers ause-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: -16or 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 onthe assumption that bridges may never go away. In this case, the fix isto move the bridge registration in the pmic_glink_altmode driver toafter all resources have been looked up.Incidentally, with the new dp-hpd bridge implementation, which registerschild devices, this is also a requirement due to a long-standing issuein driver core that can otherwise lead to a probe deferral loop (seecommit fbc35b45f9f6 ( Add documentation on meaning of -EPROBE_DEFER )).[DB: slightly fixed commit message by adding the word commit ]
| NVD | openEuler | |
|---|---|---|
| CVSS评分 | 5.5 | 5.5 |
| Attack Vector | Local | Local |
| Attack Complexity | Low | High |
| Privileges Required | Low | High |
| User Interaction | None | None |
| Scope | Unchanged | Unchanged |
| Confidentiality | None | None |
| Integrity | None | None |
| Availability | High | None |
| 公告名 | 概要 | 发布时间 |
|---|---|---|
| KylinSec-SA-2024-2052 | In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pmic_glink_altmode: fix drm bridge use-after-freeA recent DRM series purporting to simplify support for transparentbridges and handling of probe deferrals ironically exposed ause-after-free issue on pmic_glink_altmode probe deferral.This has manifested itself as the display subsystem occasionally failingto initialise and NULL-pointer dereferences during boot of machines likethe Lenovo ThinkPad X13s.Specifically, the dp-hpd bridge is currently registered before allresources have been acquired which means that it can also bederegistered 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 andstored a (non-reference-counted) pointer to the bridge which is about tobe deallocated.When the display controller is later initialised, this triggers ause-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: -16or 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 onthe assumption that bridges may never go away. In this case, the fix isto move the bridge registration in the pmic_glink_altmode driver toafter all resources have been looked up.Incidentally, with the new dp-hpd bridge implementation, which registerschild devices, this is also a requirement due to a long-standing issuein driver core that can otherwise lead to a probe deferral loop (seecommit fbc35b45f9f6 ( Add documentation on meaning of -EPROBE_DEFER )).[DB: slightly fixed commit message by adding the word commit ] | 2024年5月27日 |
| 产品 | 包 | 状态 |
|---|---|---|
| KY3.4-4A | kernel | Unaffected |
| KY3.4-5 | kernel | Unaffected |
| KY3.5.1 | kernel | Unaffected |
| KY3.5.2 | kernel | Unaffected |
| V6 | kernel | Unaffected |
