CVE-2026-43207

What it actually does

This flaw is in the Linux kernel MediaTek MDP media driver probe path. Incorrect error handling can leave media-to-memory device resources registered after a failed probe, leak platform-device references, and fail to handle a null return from vpu_get_plat_device(), creating a null pointer dereference condition. A local user able to influence driver probing, device binding, module loading, or related media device initialization paths could cause kernel instability or a crash. The practical impact is primarily local denial of service on systems using the affected MediaTek MDP driver; the CVSS vector indicates high confidentiality, integrity, and availability impact, but the public description points to crash/resource-leak behavior rather than a mature privilege-escalation technique.

Why it matters to the business

Systems that rely on affected Linux kernels and MediaTek MDP hardware may become unstable, crash, or lose media-processing functionality if the vulnerable driver path is triggered. This is most relevant to embedded, ARM, mobile, appliance, or edge platforms using MediaTek SoCs. It is not listed in CISA KEV, has no known public exploit maturity, is not associated with ransomware use, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, local users or workloads on shared devices could still cause operational disruption.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system where the MediaTek MDP driver is present and can be initialized, reprobed, rebound, or otherwise exercised. The attacker then triggers conditions that cause the mtk-mdp probe function to fail or receive an unexpected null platform-device result. Because the vulnerable code path does not correctly unregister previously initialized media-to-memory resources and does not safely handle the null platform-device case, the kernel may dereference a null pointer or accumulate leaked references/resources. The likely observable result is a kernel oops, panic, driver failure, or progressive instability. There is currently no indication from the provided data of public exploitation, KEV listing, ransomware use, or named threat-actor activity.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the MediaTek MDP probe error-handling path. Because no exact fixed package versions were provided, use the latest security kernel from the operating-system or device vendor and confirm the vendor advisory explicitly includes this fix. Where patching is not immediately possible, reduce exposure by disabling or blacklisting the mtk-mdp driver if the MediaTek MDP hardware/media pipeline is not required, preventing untrusted local users from loading modules or rebinding platform drivers, restricting access to media device nodes, and applying standard hardening such as module-signing enforcement and least-privilege access controls.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel contains the affected mtk-mdp driver code and whether the system uses MediaTek MDP hardware. Validate remediation by verifying the installed kernel version against the vendor's fixed kernel advisory or by confirming the patched code path includes cleanup with mtk_mdp_unregister_m2m_device(), null-return handling for vpu_get_plat_device(), and platform_device_put() for the returned platform device. Operationally, reboot into the fixed kernel, confirm the vulnerable kernel is no longer running, and check that mtk-mdp driver initialization succeeds without kernel oops, panic, reference-leak warnings, or probe-failure errors in kernel logs.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel with the MediaTek MDP driver available.
2. Identify whether the mtk-mdp driver is loaded, built into the kernel, or can be triggered through platform-device probing or driver binding.
3. Trigger driver probe, reprobe, bind/unbind, module load, or media-device initialization behavior that forces the vulnerable error-handling path.
4. Cause vpu_get_plat_device() failure or a probe failure after partial driver initialization.
5. Kernel dereferences a null pointer or leaks driver/platform-device resources.
6. System experiences kernel oops, panic, media driver failure, or degraded stability.

How to detect it

Review kernel and system logs for signs of prior crashes or exploitation attempts involving the MediaTek MDP driver. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, persistent pstore/ramoops crash logs, crash dumps, and audit logs for module loading or sysfs driver bind/unbind activity. Look for kernel oops or panic events near mtk-mdp probe failures, null pointer dereference messages, repeated loading or unloading of media/platform drivers, or unusual writes to /sys/bus/platform/drivers/*/bind and /sys/bus/platform/drivers/*/unbind. Because there are no known public exploit indicators, KEV entry, ransomware association, or named threat actors in the provided data, detection should focus on behavioral evidence of driver-triggered kernel faults rather than fixed network IOCs.

• mtk-mdp
• mtk_mdp
• vpu_get_plat_device
• mtk_mdp_unregister_m2m_device
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• /sys/bus/platform/drivers/mtk-mdp/bind
• /sys/bus/platform/drivers/mtk-mdp/unbind
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore
• ramoops

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and ARM platforms that use MediaTek SoCs or load the mtk-mdp driver.
• Prioritize patching systems where untrusted local users, containers, kiosks, third-party workloads, or exposed management interfaces can reach local kernel attack surfaces.
• Apply the latest vendor-supported kernel update that includes the mtk-mdp probe error-handling fix; no exact fixed versions were provided in the input.
• If patching is delayed, disable or blacklist the mtk-mdp driver where media-processing functionality is not required.
• Restrict permissions on media device nodes and prevent unprivileged users from loading kernel modules or rebinding platform drivers.
• Monitor kernel logs for null pointer dereferences, oopses, panics, mtk-mdp probe failures, and repeated driver bind/unbind activity.
• Treat this as lower external-exploitation priority than KEV or high-EPSS issues, but do not ignore it on shared or physically accessible systems.