CVEvulnerability

CVE-2024-26874

4.7 MEDIUM Published 2024-04-17 Modified 2026-06-17 Official page ↗
Status
Analyzed
Published
2024-04-17
Last modified
2026-06-17
Assigner
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS 3.1 ([email protected])
4.7 MEDIUM — CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses
CWE-476

Description

In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use.

Affected configurations

• linux linux kernel (>= 4.7 < 4.19.311) • linux linux kernel (>= 4.20 < 5.4.273) • linux linux kernel (>= 5.5 < 5.10.214) • linux linux kernel (>= 5.11 < 5.15.153) • linux linux kernel (>= 5.16 < 6.1.83) • linux linux kernel (>= 6.2 < 6.6.23) • linux linux kernel (>= 6.7 < 6.7.11) • linux linux kernel (>= 6.8 < 6.8.2) • debian debian linux 10.0

Related

Weakness · CWE (1)

  • CWE-476 NULL Pointer Dereference weakness

References