CVE-2024-26909
soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
Severity Score
Exploit Likelihood
Affected Versions
Public Exploits
0Exploited in Wild
-Decision
Descriptions
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']
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free Una serie reciente de DRM que pretende simplificar el soporte para "puentes transparentes" y el manejo de aplazamientos de sonda expuso irónicamente un uso posterior -Problema gratuito en el aplazamiento de la sonda pmic_glink_altmode. Esto se ha manifestado como que el subsistema de visualización ocasionalmente falla al inicializarse y se eliminan las referencias del puntero NULL durante el arranque de máquinas como la Lenovo ThinkPad X13s. Específicamente, el puente dp-hpd actualmente está registrado antes de que se hayan adquirido todos los recursos, lo que significa que también se puede cancelar su registro en caso de aplazamientos de sonda. Mientras tanto, hay una ventana de carrera donde el nuevo controlador del puente auxiliar (o el controlador PHY anteriormente) puede haber buscado el puente dp-hpd y almacenado un puntero (sin recuento de referencias) al puente que está a punto de ser desasignado. Cuando el controlador de pantalla se inicializa posteriormente, esto activa un use-after-free al conectar los puentes: dp -> aux -> dp-hpd (liberado) que puede, por ejemplo, provocar que el puente liberado no se pueda conectar: [drm :drm_bridge_attach [drm]] *ERROR* no se pudo adjuntar el puente /soc@0/phy@88eb000 al codificador TMDS-31: -16 o una desreferencia de puntero NULL: no se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000000... Seguimiento de llamadas: 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] El puente DRM la implementación es claramente frágil e implícitamente construido sobre el supuesto de que es posible que los puentes nunca desaparezcan. En este caso, la solución es mover el registro del puente en el controlador pmic_glink_altmode después de que se hayan buscado todos los recursos. Por cierto, con la nueva implementación del puente dp-hpd, que registra dispositivos secundarios, esto también es un requisito debido a un problema de larga data en el núcleo del controlador que, de lo contrario, puede provocar un bucle de aplazamiento de la sonda (consulte el compromiso fbc35b45f9f6 ("Agregar documentación sobre el significado de -EPROBE_DEFER")). [DB: mensaje de confirmación ligeramente corregido agregando la palabra 'compromiso']
CVSS Scores
SSVC
- Decision:Track
Timeline
- 2024-02-19 CVE Reserved
- 2024-04-17 CVE Published
- 2024-04-30 EPSS Updated
- 2024-12-19 CVE Updated
- ---------- Exploited in Wild
- ---------- KEV Due Date
- ---------- First Exploit
CWE
- CWE-416: Use After Free
CAPEC
References (4)
URL | Tag | Source |
---|---|---|
https://git.kernel.org/stable/c/080b4e24852b1d5b66929f69344e6c3eeb963941 | Vuln. Introduced |
URL | Date | SRC |
---|
URL | Date | SRC |
---|
Affected Vendors, Products, and Versions
Vendor | Product | Version | Other | Status | ||||||
---|---|---|---|---|---|---|---|---|---|---|
Vendor | Product | Version | Other | Status | <-- --> | Vendor | Product | Version | Other | Status |
Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 6.3 < 6.6.23 Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.6.23" | en |
Affected
| ||||||
Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 6.3 < 6.7.11 Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.7.11" | en |
Affected
| ||||||
Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 6.3 < 6.8 Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.8" | en |
Affected
|