CVE-2026-89885 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
media: platform: mtk-mdp3: Fix SCP device refcounting
mdp_probe() first tries to get the SCP handle with scp_get(). When that fails, it falls back to looking up the SCP platform device with __get_pdev_by_id() and then reads its driver data.
The fallback lookup returns the platform device with a reference, just like scp_get() does. However, the fallback path currently drops that reference immediately after platform_get_drvdata(). The driver later still calls scp_put(mdp->scp) unconditionally from the probe error path and from mdp_video_device_release(), which drops the SCP device reference again.
Keep the fallback reference until the existing scp_put() call, so that the fallback path follows the same ownership rules as the scp_get() path.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel media subsystem specifically affects the MediaTek MDP3 driver component located at mtk-mdp3. This issue stems from an incorrect handling of reference counting for System Control Processor (SCP) device objects during the initialization and error recovery phases of the driver probe routine. The core technical flaw lies in a mismatch between how references are acquired through different code paths and how they are subsequently released, leading to premature deallocation or double-free scenarios depending on execution flow.
During the mdp_probe function execution, the driver attempts to acquire an SCP handle using the scp_get() API. This standard path correctly increments the reference count of the target device object, ensuring that the kernel maintains a valid pointer for as long as the driver requires access to the hardware resources. However, when this primary acquisition method fails, the code falls back to an alternative mechanism involving __get_pdev_by_id(). This fallback function also returns a platform device with its internal reference count incremented, mirroring the behavior of scp_get() in terms ownership semantics. The critical error occurs immediately after retrieving driver data via platform_get_drvdata(), where the current implementation erroneously decrements or drops this reference count prematurely.
This premature release creates a dangling pointer situation because subsequent operations within the probe function and later lifecycle events assume that the SCP device remains valid. Specifically, the code path includes an unconditional call to scp_put(mdp->scp) in both the probe error handling section and during mdp_video_device_release(). Since the reference was already dropped by the flawed fallback logic, these subsequent put calls result in a double-free vulnerability or use-after-free condition if the device structure has been freed due to zero refcount. This violates fundamental kernel memory safety principles where every get operation must have exactly one corresponding put operation at the appropriate lifecycle stage.
From a security perspective, this type of reference counting error falls under CWE-416: Use After Free and CWE-362: Concurrent Execution Using Shared Resource with Improper Synchronization. In practice, an attacker who can trigger the probe failure path might exploit the use-after-free condition to corrupt kernel memory structures or execute arbitrary code within the kernel space by manipulating freed objects before they are reallocated for other purposes. The ATT&CK framework categorizes such vulnerabilities under T1059: Command and Scripting Interpreter if exploited via scriptable interfaces, but more accurately aligns with techniques involving exploitation of binary vulnerabilities in system software components like T1203 or general privilege escalation vectors enabled by memory corruption flaws.
The operational impact of this vulnerability includes potential kernel panics due to invalid pointer dereferences when the freed memory is accessed unexpectedly. Furthermore, it poses a severe risk for local privilege escalation attacks where malicious users with limited access could trigger the specific code path leading to the double-free scenario. This compromises system stability and confidentiality by allowing unauthorized modification of critical kernel data structures or execution of arbitrary instructions in ring 0 privileges.
To mitigate this vulnerability, developers must ensure that reference counting semantics are consistent across all acquisition paths within the driver. The fix involves retaining the SCP device reference obtained through the __get_pdev_by_id() fallback path until it is explicitly released by a corresponding scp_put() call. This aligns the ownership rules of the fallback mechanism with those of the primary scp_get() path, ensuring that every increment in refcount has a matching decrement at the correct point in the object lifecycle. Proper synchronization and adherence to kernel reference counting guidelines prevent premature deallocation and eliminate the window for use-after-free exploitation.