CVE-2024-26874: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip

Severity: medium (CVSS 4.7 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.2% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2024-04-17 · updated 2026-06-17
Weakness: 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 products

Debian Linux: 10.0
Linux kernel: from 4.7 before 4.19.311; from 4.20 before 5.4.273; from 5.5 before 5.10.214; from 5.11 before 5.15.153; from 5.16 before 6.1.83; from 6.2 before 6.6.23 — fixed in 4.19.311, 5.10.214, 5.15.153, 5.4.273, 6.1.83, 6.6.23

How to fix

Upgrade to a fixed version: Linux kernel 4.19.311, 5.10.214, 5.15.153, 5.4.273. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2024-26874 or the next vulnerability affects your stack