CVE-2026-89512

What it actually does

The MediaTek SCP remoteproc driver in the Linux kernel takes a reference on the SCP device while looking up driver data before the driver is bound, then fails to drop that reference on the unsuccessful path. The leaked device reference keeps the device object and associated kernel memory alive indefinitely, can block unbind/remove, and does not keep driver data valid—so subsequent use of stale driver data is also possible. Repeated hits on this path can exhaust kernel resources and produce a local denial of service on platforms that use this driver.

Why it matters to the business

Impact is limited to Linux systems that use the MediaTek SCP remote processor (typically embedded, mobile, or IoT devices), not general-purpose servers. This is not on the CISA KEV list, has no reported ransomware use, has no public exploit (maturity: none), and has a very low, flat EPSS (~0.22% with no 30-day change) about a month after publication. Expected business effect is local instability or resource leakage rather than remote breach, data theft, or widespread outage. Treat as routine kernel patching, not an emergency.

How an attack unfolds

There is no known in-the-wild exploitation, named threat-actor use, or public exploit. A local actor on an affected MediaTek SCP platform would need to cause the SCP driver-data lookup to run before the driver is bound—via device enumeration, probe/bind races, module load/unload, or remoteproc control paths—so the kernel takes a device reference and never releases it. Repeating that failed-lookup path inflates the device refcount, prevents teardown, and can starve kernel memory or leave the SCP device unmanageable. This is a local resource-leak denial of service, not a remote or unauthenticated attack.

How to fix it

Apply the upstream Linux kernel fix for the remoteproc SCP device-reference leak (drop the SCP device reference when driver-data lookup runs before bind). Deploy a vendor or distribution kernel that includes that change; no specific fixed version numbers were published with this record. Until patched, restrict unprivileged access to remoteproc/SCP interfaces, avoid unnecessary load/unload of the SCP remoteproc driver, and prioritize MediaTek SCP-based embedded/mobile images in the normal kernel update cycle.

How to confirm the fix worked

Confirm the running kernel includes the remoteproc SCP reference-leak fix via vendor advisory, distro changelog, or kernel git history for the SCP driver. After update, exercise SCP/remoteproc probe and failed-lookup paths and verify the SCP device reference count returns to baseline and the device can bind, unbind, and be removed cleanly without growing kmalloc/kobject usage. Systems without MediaTek SCP hardware are not exposed.

Typical attack path

1. Gain local (or equivalently privileged device-management) access on a Linux system that uses the MediaTek SCP remoteproc driver.
2. Trigger SCP device driver-data lookup before the SCP driver has bound, for example through probe/bind races, module reload, or remoteproc device operations.
3. Cause the lookup to fail so the acquired device reference is not dropped.
4. Repeat the failed-lookup path to accumulate leaked references and unreclaimed device memory.
5. Observe blocked device teardown, kernel memory growth, or SCP/remoteproc unavailability consistent with local denial of service.

How to detect it

There are no public exploits, KEV mappings, or attributed campaigns, so compromise-specific hunting has low yield. On MediaTek SCP hosts, review kernel logs around remoteproc/SCP probe and bind failures, watch for steadily climbing device/kobject reference counts or unreclaimable slab usage tied to the SCP device after failed lookups, and note inability to unbind or remove the SCP remoteproc device without reboot. Unexpected module load/unload of the SCP remoteproc driver or repeated remoteproc sysfs operations by unprivileged users are weaker supporting signals. Network telemetry will not show this bug. Absence of these artifacts does not prove the flaw was never hit; it often looks like a leak rather than a distinct exploit event.

What your security team should do

• Inventory Linux assets for MediaTek SCP / mtk remoteproc usage; deprioritize hosts without that hardware.
• Roll the kernel patch through the normal patch window; this is not KEV and does not warrant emergency change.
• Until patched, limit who can load modules or operate remoteproc/SCP device nodes on affected platforms.
• Do not invest in dedicated detection content beyond general kernel-health monitoring; EPSS is low and stable and exploit maturity is none.
• Re-check vendor kernel notes on the next merge cycle in case fixed version mapping is published later.