CVE-2026-43270

What it actually does

This is a local availability flaw in the Linux kernel MediaTek MDP media driver. During device probing, the driver obtains a referenced platform device via vpu_get_plat_device(), but the corresponding remove path did not release that reference. Repeated probe/remove cycles can leak kernel references and associated resources, eventually contributing to kernel memory/resource exhaustion or unstable device-driver state. The practical impact is denial of service rather than data disclosure or privilege escalation.

Why it matters to the business

Systems using affected Linux kernels with the MediaTek MDP driver enabled may be vulnerable to local disruption. An attacker who already has local access, or software capable of repeatedly triggering driver removal/rebind behavior, could degrade or crash affected devices. This is most relevant for MediaTek-based embedded, mobile, appliance, and edge systems where kernel updates are often tied to vendor firmware releases. The CVSS score indicates moderate severity, EPSS is very low, it is not listed in CISA KEV, and there is no known exploit maturity, so remediation should be scheduled through normal kernel/firmware maintenance unless the affected driver is exposed on high-availability systems.

How an attack unfolds

An attacker first gains local access to an affected Linux system where the MediaTek MDP driver is present and active. They then attempt to repeatedly exercise the driver lifecycle, such as by causing the platform device or module to be removed and re-probed through available administrative, service, or device-management interfaces. Each vulnerable removal path fails to drop a platform-device reference acquired during probe. Over time, leaked references and related resources can accumulate. If repeated enough, this can cause memory pressure, driver instability, failed device operations, hung tasks, or system crash conditions, resulting in denial of service. Exploitation does not provide direct confidentiality or integrity impact.

How to fix it

Update to a Linux kernel or vendor firmware build that includes the upstream fix for the MediaTek MDP driver reference leak. The corrective change adds the missing platform_device_put() in mtk_mdp_remove() to release the reference obtained during probe. No exact fixed package versions were provided in the input, so use the fixed kernel version from the relevant distribution, SoC vendor, device OEM, or long-term-stable kernel branch. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the mtk-mdp driver if the hardware function is not required, restricting local shell access, limiting permissions to sysfs driver bind/unbind controls, preventing untrusted users from loading/unloading kernel modules, and monitoring for repeated device-driver lifecycle operations.

How to confirm the fix worked

Confirm the running kernel or firmware build contains the driver patch that calls platform_device_put() from mtk_mdp_remove(). Validate through vendor advisory mapping, kernel changelog review, source/package inspection, or comparison against a known fixed kernel tree. On affected hardware, confirm that the MediaTek MDP driver is either not present, not loaded, disabled by policy, or updated. If testing is safe in a lab, repeatedly bind/unbind or load/unload the driver and verify that kernel memory usage, reference counts, and dmesg output remain stable and no hung tasks, OOM events, or driver warnings occur. Production validation should avoid stress-testing that could trigger denial of service.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel with the MediaTek MDP driver enabled.
2. Determine whether the mtk-mdp/MediaTek MDP platform driver is loaded or bound to hardware.
3. Trigger repeated driver remove/rebind, module unload/load, device reset, or equivalent lifecycle operations if permitted.
4. Cause the vulnerable remove path to leak platform-device references on each cycle.
5. Continue the loop until resource exhaustion, driver malfunction, kernel instability, or system denial of service occurs.

How to detect it

There are no reliable public indicators that uniquely prove exploitation of this flaw. To investigate possible prior abuse, review kernel logs, audit logs, EDR telemetry, and command-history sources for repeated driver lifecycle activity involving MediaTek MDP components. Useful sources include dmesg, journalctl/kern.log, auditd records for writes to sysfs driver bind/unbind files, process execution logs for modprobe/rmmod/insmod, and crash/OOM telemetry. Look for clusters of repeated remove/reprobe activity followed by memory pressure, OOM killer events, hung tasks, kernel warnings, media-device failures, or unexpected reboots. Because this vulnerability causes denial of service through a reference leak, detection is primarily behavioral and circumstantial rather than based on a stable payload signature.

What your security team should do

• Inventory Linux systems and firmware images that use MediaTek SoCs or have the mtk-mdp MediaTek MDP driver enabled.
• Prioritize patching through vendor kernel, appliance, mobile, or embedded firmware updates where the driver is present.
• If patching is delayed, disable or blacklist the mtk-mdp driver where it is not operationally required.
• Restrict local administrative interfaces that can trigger kernel module load/unload or sysfs driver bind/unbind operations.
• Add monitoring for repeated driver bind/unbind activity, rmmod/modprobe activity involving MediaTek MDP components, kernel OOM events, and sudden device instability.
• Treat exploitation likelihood as currently low because EPSS is very low, the issue is not in KEV, and no public exploit maturity is reported; however, do not defer indefinitely on devices where availability is critical.