The Linux kernel MediaTek MDP driver contains an error handling flaw in its probe routine that allows a null pointer dereference and insufficient cleanup of platform devices. When the driver attempts to retrieve a platform device via vpu_get_plat_device() and the return value violates the expected contract, the kernel may access a null pointer, leading to a crash. The added call to mtk_mdp_unregister_m2m_device() on the error path and the insertion of platform_device_put() aim to eliminate resource leaks that could otherwise accumulate reference counts. Based on the description, the likely attack vector requires privilege to load or trigger the malformed probe routine—most likely a local user or administrator who can load kernel modules or influence device enumeration. The primary impact is a denial of service, as a single failed probe can bring down the kernel, and in some scenarios, this crash could be leveraged for privilege escalation if the system is not rebooted securely. At the time of analysis, no CVSS score is publicly available, and EPSS is not provided. The vulnerability is not listed in the CISA KEV catalog, suggesting limited or no known exploitation. However, because the issue resides in kernel code, the potential for a local privilege escalation or fork‑jail escape is elevated. The risk can be considered moderate to high for systems that run the driver without the applied fix and support untrusted users performing module load operations.

The vulnerability affects the Linux kernel, specifically the MediaTek MDP (mtk-mdp) driver. The kernel's probe failure and resource management bugs are present in all kernel versions before the patch commits referenced; exact affected kernel releases are not enumerated.

At the time of analysis, no CVSS score is publicly available, and EPSS is not provided. The vulnerability is not listed in the CISA KEV catalog, suggesting limited or no known exploitation. However, because the issue resides in kernel code, the potential for a local privilege escalation or fork‑jail escape is elevated. The risk can be considered moderate to high for systems that run the driver without the applied fix and support untrusted users performing module load operations.