A vulnerability has been discovered and resolved within the Linux kernel that affects the drm/mediatek implementation. Specifically, the vulnerability relates to a null pointer crash in mtk_drm_crtc_finish_page_flip(). In this article, we will discuss the vulnerability, provide code snippets, original references, and further details on the exploit.
Exploit Details
The vulnerability exists due to a possible race condition in the handling of mtk_crtc->event within the mtk_drm_crtc_finish_page_flip() function in the Linux kernel drm/mediatek implementation. The pending_needs_vblank value is set by mtk_crtc->event, but in the mtk_drm_crtc_atomic_flush() function, it is not guarded by the same lock that’s used in mtk_drm_finish_page_flip(). Consequently, a race condition occurs.
A possible scenario that could trigger the vulnerability is as follows
CPU1 CPU2
step 1
mtk_drm_crtc_atomic_begin()
mtk_crtc->event is not null,
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 is still true
//null pointer
In this scenario, CPU1 and CPU2 are simultaneously executing code that manipulates the mtk_crtc->event. Due to the absence of proper locks, it leads to a null pointer crash when mtk_drm_crtc_finish_page_flip() is called with a pending_needs_vblank value that is still set to true.
Solution
Instead of guarding the entire mtk_drm_crtc_atomic_flush() function, a more efficient solution is to check if mtk_crtc->event is null before use. By implementing this change, the vulnerability has been resolved.
Original References
- Linux kernel mailing list
- GitHub Merge commit
Conclusion
CVE-2024-26874 highlighted a vulnerability in the Linux kernel drm/mediatek implementation due to a race condition involving mtk_crtc->event. The issue has now been resolved by properly checking the null status of mtk_crtc->event before its use. It is essential for Linux kernel maintainers and users to stay informed of such vulnerabilities and apply fixes to ensure the security and stability of their systems.
Timeline
Published on: 04/17/2024 11:15:09 UTC
Last modified on: 03/03/2025 17:47:59 UTC