CVE-2026-46308

What it actually does

This is a Linux kernel use-after-free flaw in the MediaTek power-domain driver error path. During device-tree probing, scpsys_get_bus_protection_legacy() obtains a device-node reference, releases it with of_node_put(), and then may still pass the released node to dev_err_probe() if syscon_regmap_lookup_by_phandle() fails. On affected MediaTek-based systems, this can cause kernel memory to be accessed after it has been freed, most likely resulting in a kernel warning, crash, or denial of service during device initialization. Practical exploitation for privilege escalation is not currently demonstrated and would likely depend on precise kernel memory reuse conditions and the ability to influence device-tree or probe failure behavior.

Why it matters to the business

The most likely operational impact is instability or boot/probe failures on Linux systems using affected MediaTek SoCs or kernels with the vulnerable driver enabled. Because exploitation maturity is currently reported as none, EPSS is very low, and the issue is not in CISA KEV or associated with ransomware campaigns, broad internet-scale exploitation is unlikely at this time. The primary business risk is service disruption for embedded, mobile, IoT, edge, or appliance products built on affected MediaTek platforms, especially where kernel updates are slow or device fleets are difficult to patch.

How an attack unfolds

An attacker would need a way to influence the conditions under which the MediaTek power-domain driver probes device-tree nodes and fails a syscon phandle lookup. When the vulnerable function discovers a relevant device-tree node, it incorrectly drops the node reference before completing error handling. If the lookup then fails, the kernel diagnostic path dereferences the stale node pointer while formatting the probe error. If the freed memory has not been reused, the result may be benign or a kernel warning; if it has been reused or invalidated, the result may be a kernel crash. Turning this into controlled code execution would require reliable shaping of kernel heap state around a narrow driver initialization error path, and no public exploit is currently known.

How to fix it

Apply a Linux kernel version or vendor kernel update that includes the fix moving of_node_put() until after the syscon_regmap_lookup_by_phandle() error check in the MediaTek pmdomain driver. Because no exact fixed package versions were provided, track updates from the relevant Linux distribution, device vendor, board support package provider, or upstream kernel stable branch. For products built from source, backport the upstream patch for pmdomain: mediatek: scpsys_get_bus_protection_legacy(). If immediate patching is not possible, reduce exposure by avoiding untrusted or dynamically supplied device-tree overlays, restricting bootloader and firmware configuration changes to trusted administrators, and disabling unused MediaTek platform drivers where safe and supported.

How to confirm the fix worked

Confirm the running kernel includes the patched MediaTek pmdomain driver source or vendor advisory fix. For source-based builds, inspect drivers/pmdomain/mediatek/ and verify that scpsys_get_bus_protection_legacy() does not call of_node_put(node) before the syscon_regmap_lookup_by_phandle() error path finishes using node. For packaged systems, verify the installed kernel package is at or above the vendor-fixed release once published. On applicable MediaTek hardware, reboot or reprobe the platform under normal configuration and confirm there are no kernel warnings, KASAN use-after-free reports, probe-time crashes, or pmdomain/scpsys-related errors in dmesg or journal logs.

Typical attack path

1. Identify a Linux system running an affected kernel with the MediaTek pmdomain/scpsys driver enabled and relevant MediaTek device-tree configuration.
2. Obtain a way to alter, supply, or trigger problematic device-tree/probe conditions, such as during boot, driver initialization, or platform integration testing.
3. Cause syscon_regmap_lookup_by_phandle() to fail after scpsys_get_bus_protection_legacy() has released the device-node reference.
4. Trigger the error-reporting path that calls dev_err_probe() using the stale device-node pointer.
5. Observe likely outcomes such as kernel warning, driver probe failure, boot instability, or kernel panic; more advanced exploitation would require controlled memory reuse and is not currently established.

How to detect it

There are no known public exploitation indicators, named threat actors, KEV activity, or ransomware usage associated with this issue. Detection should focus on evidence of attempted triggering or observed fault conditions on affected MediaTek Linux systems. Review kernel logs from dmesg, journalctl -k, serial console output, crash dumps, pstore/ramoops, and KASAN/KFENCE reports for references to scpsys_get_bus_protection_legacy(), MediaTek pmdomain/scpsys probing, syscon_regmap_lookup_by_phandle() failures, use-after-free reports, kernel oopses, or panics during boot or driver initialization. Also review configuration-change logs for unexpected firmware, bootloader, kernel, or device-tree overlay modifications, because practical triggering likely requires influence over platform configuration rather than a typical remote network request.

• scpsys_get_bus_protection_legacy
• syscon_regmap_lookup_by_phandle
• pmdomain: mediatek
• mediatek scpsys
• use-after-free
• KASAN: use-after-free
• kernel BUG
• Unable to handle kernel paging request
• Oops:
• Kernel panic

What your security team should do

• Prioritize remediation for products and fleets using MediaTek-based Linux kernels, embedded appliances, IoT devices, edge systems, or custom board support packages.
• Track vendor kernel advisories and stable-kernel backports because no universal fixed version was provided in the input.
• If maintaining a custom kernel, backport the upstream fix directly and rebuild affected device images.
• Search build configurations for MediaTek pmdomain/scpsys driver enablement to determine practical exposure.
• Restrict who can modify bootloader settings, firmware images, kernel command lines, and device-tree overlays on affected platforms.
• Monitor kernel logs on affected devices for pmdomain, scpsys, KASAN, use-after-free, or boot/probe instability signals.
• Treat this as a stability and platform-hardening issue unless new exploit evidence emerges, since current EPSS is low, exploit maturity is none, and it is not listed in KEV.