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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 8.4
AV:L - The extra put_device is in mdp_probe()/mdp_video_device_release of the MediaTek MDP3 platform driver, reached only via local driver-model bind on MT8183/MT8195 (boot, deferred probe, module load, or sysfs rebind). No network, Bluetooth/Wi-Fi, or USB path reaches this SCP refcounting.
AC:L - On MT8183 the MDP RDMA node has no mediatek,scp phandle, so scp_get() fails and the compatible fallback is the production path. That path drops the of_find_device_by_node() ref then later scp_put() extra-puts; cmdq mailbox EPROBE_DEFER after the fallback makes this deterministic with no race.
PR:N - mdp_probe() runs in driver-core context with no capable() or credential check. On MediaTek Chromebooks, phones, and embedded boards, MDP3 commonly deferred-probes at boot after the SCP fallback, so the extra put fires without a user account.
UI:N - Platform probe and deferred-probe retries run unattended at boot or module bind on affected hardware. Opening /dev/video, mounting a filesystem, or plugging a device is not required.
S:U - The extra put_device() use-after-free is of the host SCP platform_device inside the same kernel security authority. It does not cross a VM, IOMMU/DMA, or sandbox boundary.
C:H - scp_put() extra-puts the SCP platform_device, which can run device_release and free the still-bound struct device. A use-after-free of that object enables reclaim and kernel-memory disclosure.
I:H - The same device UAF is heap corruption of struct platform_device/mtk_scp still used by the SCP driver and other scp_get() holders, enabling heap spray, arbitrary write, and control-flow hijack.
A:H - Freeing the SCP device while it remains registered, or later dereferencing the dangling scp pointer from MDP3/vcodec, causes a kernel oops or panic.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The extra put_device is in mdp_probe()/mdp_video_device_release of the MediaTek MDP3 platform driver, reached only via local driver-model bind on MT8183/MT8195 (boot, deferred probe, module load, or sysfs rebind). No network, Bluetooth/Wi-Fi, or USB path reaches this SCP refcounting.
AC:L - On MT8183 the MDP RDMA node has no mediatek,scp phandle, so scp_get() fails and the compatible fallback is the production path. That path drops the of_find_device_by_node() ref then later scp_put() extra-puts; cmdq mailbox EPROBE_DEFER after the fallback makes this deterministic with no race.
PR:N - mdp_probe() runs in driver-core context with no capable() or credential check. On MediaTek Chromebooks, phones, and embedded boards, MDP3 commonly deferred-probes at boot after the SCP fallback, so the extra put fires without a user account.
UI:N - Platform probe and deferred-probe retries run unattended at boot or module bind on affected hardware. Opening /dev/video, mounting a filesystem, or plugging a device is not required.
S:U - The extra put_device() use-after-free is of the host SCP platform_device inside the same kernel security authority. It does not cross a VM, IOMMU/DMA, or sandbox boundary.
C:H - scp_put() extra-puts the SCP platform_device, which can run device_release and free the still-bound struct device. A use-after-free of that object enables reclaim and kernel-memory disclosure.
I:H - The same device UAF is heap corruption of struct platform_device/mtk_scp still used by the SCP driver and other scp_get() holders, enabling heap spray, arbitrary write, and control-flow hijack.
A:H - Freeing the SCP device while it remains registered, or later dereferencing the dangling scp pointer from MDP3/vcodec, causes a kernel oops or panic.
CVSS 3.1