CVE-2024-26874

Source
https://nvd.nist.gov/vuln/detail/CVE-2024-26874
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-26874.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2024-26874
Downstream
Related
Published
2024-04-17T11:15:09Z
Modified
2025-08-09T20:01:26Z
Severity
  • 4.7 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: Fix a null pointer crash in mtkdrmcrtcfinishpage_flip

It's possible that mtkcrtc->event is NULL in mtkdrmcrtcfinishpageflip().

pendingneedsvblank value is set by mtkcrtc->event, but in mtkdrmcrtcatomicflush(), it's is not guarded by the same lock in mtkdrmfinishpage_flip(), thus a race condition happens.

Consider the following case:

CPU1 CPU2 step 1: mtkdrmcrtcatomicbegin() mtkcrtc->event is not null, step 1: mtkdrmcrtcatomicflush: mtkdrmcrtcupdateconfig( !!mtkcrtc->event) step 2: mtkcrtcddpirq -> mtkdrmfinishpageflip: lock mtkcrtc->event set to null, pendingneedsvblank set to false unlock pendingneedsvblank 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 mtkdrmcrtcatomicflush(), it's more efficient to just check if mtk_crtc->event is null before use.

References

Affected packages