*Published: June 2024*
Overview
A recent vulnerability, identified as CVE-2024-53056, involves a NULL pointer dereference in the Linux kernel’s MediaTek Direct Rendering Manager (DRM) driver. If triggered, this bug could crash your system (kernel panic) under the right conditions. Let’s look at what happened, how the problem got fixed, and why checking for NULL pointers is so important for secure kernel code.
What is the Problem?
In the Linux kernel’s MediaTek DRM driver, there’s a function called mtk_crtc_create(). This function tries to request a channel with mbox_request_channel(). If this request fails, it sets a pointer (mtk_crtc->cmdq_client.chan) to NULL and does not create a new packet with cmdq_pkt_create().
During cleanup, mtk_crtc_destroy() was blindly calling cmdq_pkt_destroy() with that potentially NULL pointer. Oops! If you destroy something that was never created, and the pointer is NULL, this can cause a kernel crash.
Code Snippet: The Bad Logic (Vulnerable Version)
// Called when creating a CRTC
mtk_crtc->cmdq_client.chan = mbox_request_channel(...);
if (!mtk_crtc->cmdq_client.chan) {
// channel could not be acquired
// ...handle error, but do not create packet
}
// Later, during cleanup
cmdq_pkt_destroy(mtk_crtc->cmdq_client.pkt);
If cmdq_client.chan is NULL, then pkt was never created -- but the code tries to destroy it anyway!
What Could Go Wrong?
If someone manages to trigger the cleanup path with a NULL mtk_crtc->cmdq_client.chan (say, by forcing a device error or playing with the driver loading/unloading), the kernel will dereference a NULL pointer during the call to cmdq_pkt_destroy(). In user terms: your Linux kernel crashes.
This isn’t an “exploit for root access” bug, but a denial-of-service one — potentially useful for attackers who want to crash your device or cause system instability.
The Right Way: Check for NULL!
Maintainers fixed the bug by checking if the pointer is NULL before calling the destroy function. Here’s what that fix looks like:
// Safe version: check for NULL
if (mtk_crtc->cmdq_client.chan)
cmdq_pkt_destroy(mtk_crtc->cmdq_client.pkt);
Simple! But it prevents the kernel from trying to “destroy” something that never existed.
Did I Have This Bug?
You’re only affected if you run Linux on a device with a MediaTek GPU/DRM and use a kernel before the patch.
Force the MediaTek DRM driver to allocate and then clean up a CRTC,
- Make mbox_request_channel() fail (by causing resource exhaustion, racing with other processes, or fuzzing kernel interfaces),
Wait for the cleanup path to dereference NULL and panic the kernel.
Proof-Of-Concept:
While there’s no simple public exploit yet, Linux kernel fuzzer frameworks (like Syzkaller) can and have produced crashes from this type of bug. Here’s a conceptual sequence:
Load and partially initialize the MediaTek DRM subsystem (with forced mailbox channel failure).
2. Trigger a path (such as driver unload, error recovery, or device detach) that performs the faulty cleanup.
Kernel patch commit:
CVE Record:
CVE-2024-53056 (MITRE) *(will update as available)*
Original Kernel Mailing List Report:
https://lore.kernel.org/all/20240510191022.361449-1-sharer.yue@mediatek.com/
Syzkaller kernel fuzzer:
https://github.com/google/syzkaller
Bottom Line
CVE-2024-53056 shows that *small mistakes* — like not checking for NULL — can cause big headaches in systems code. The Linux kernel devs fixed this right away. If your kernel (or Android firmware) uses MediaTek’s DRM driver, ask your vendor for an update!
Timeline
Published on: 11/19/2024 18:15:25 UTC
Last modified on: 11/22/2024 17:55:51 UTC