CVE-2024-26874

2024-04-1711:15:09

416baaa9-dc9f-4396-8d5f-8c081fb06d67

web.nvd.nist.gov

linux kernel

vulnerability

fix

null pointer crash

mtk_drm_crtc_finish_page_flip

race condition

cpu1

cpu2

lock

unlock

efficient

cve

7.4 High

AI Score

Confidence

High

0.0004 Low

EPSS

Percentile

13.0%

JSON

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 -&gt;
                              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.