DEBIAN-CVE-2024-26874
- Source
- https://security-tracker.debian.org/tracker/CVE-2024-26874
- Import Source
- https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2024-26874.json
- JSON Data
- https://api.osv.dev/v1/vulns/DEBIAN-CVE-2024-26874
- Upstream
- Downstream
- Published
- 2024-04-17T11:15:09Z
- Modified
- 2026-09-15T09:03:01Z
- 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 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.
- References
Affected packages
Debian:12 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source&distro=bookworm
Affected ranges
- Type
- ECOSYSTEM
- Events
-
Introduced0 Unknown introduced version / All previous versions are affectedFixed6.1.85-1
Debian:13 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source&distro=trixie
Debian:14 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source&distro=forky