CVE-2026-45881

What it actually does

This is a local Linux kernel denial-of-service flaw in the MediaTek Smart Voltage Scaling (SVS) driver debug write path. The vulnerable function allocates a user-supplied buffer with memdup_user_nul() and, if integer parsing with kstrtoint() fails, returns without freeing that buffer. A local user who can write to the affected SVS debug interface can repeatedly submit malformed values, causing unreclaimed kernel memory allocations. Over time this can exhaust kernel memory and degrade or crash the system. The issue does not provide code execution, privilege escalation, or data disclosure based on the published description; the primary impact is availability loss.

Why it matters to the business

Systems running affected Linux kernels on MediaTek platforms may be vulnerable to local resource-exhaustion attacks that can cause instability, service interruption, or device reboots. The practical business risk is highest for shared, kiosk, edge, mobile, appliance, or embedded Linux deployments where untrusted or semi-trusted local users, applications, containers, or services may reach debugfs or the SVS debug controls. The CVSS score is moderate, EPSS is currently very low, it is not listed in CISA KEV, and no mature exploit is reported, so this should generally be handled through normal kernel patch management unless exposed debug interfaces are accessible to untrusted users.

How an attack unfolds

An attacker first needs local access to a system using the affected MediaTek SVS kernel driver and access to the vulnerable debug write interface, typically through a mounted debugfs hierarchy or an equivalent vendor-exposed debug control. The attacker writes malformed non-integer input to the SVS enable debug file. The kernel copies the user buffer, attempts to parse it as an integer, and exits the error path without freeing the allocation. By automating many invalid writes, the attacker accumulates leaked kernel memory. If repeated enough, the system may experience memory pressure, failed allocations, degraded workloads, watchdog resets, or a kernel panic. Because exploitation depends on local access and writable debug controls, hardened systems that do not mount debugfs or restrict debugfs permissions are significantly less exposed.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that contains the upstream fix for the MediaTek SVS svs_enable_debug_write() memory leak. No exact fixed package versions were provided, so use distribution, Android BSP, appliance, or device-vendor advisories to identify the corrected build for each affected platform. If immediate patching is not possible, reduce exposure by unmounting debugfs where not required, preventing debugfs from being mounted in production, restricting access to /sys/kernel/debug to trusted administrators only, disabling or removing the affected MediaTek SVS debug interface if operationally safe, and ensuring untrusted applications or containers cannot write to kernel debug controls. Kernel configuration and hardening should ensure CONFIG_DEBUG_FS and platform debug interfaces are not enabled on production images unless explicitly needed.

How to confirm the fix worked

Confirm remediation by verifying the running kernel build includes the fix in the MediaTek SVS driver, specifically that the error path after memdup_user_nul() no longer leaks the buffer when kstrtoint() fails. Source or package validation can look for the corrected use of automatic cleanup, such as __free(kfree), in svs_enable_debug_write() and the required cleanup.h include. Operationally, verify the host is running the patched kernel after reboot with uname and package-manager metadata, then confirm debugfs is either not mounted or restricted to trusted users. Where safe in a non-production test environment, repeated invalid writes to the SVS debug enable file should not cause sustained unreclaimed kernel memory growth after applying the fix.

Typical attack path

1. Gain local shell, application execution, or another local execution primitive on a Linux system using an affected MediaTek kernel driver.
2. Confirm that debugfs or the relevant SVS debug interface is mounted and writable.
3. Locate the MediaTek SVS debug control associated with enabling or disabling SVS behavior.
4. Repeatedly write malformed, non-integer input to the vulnerable debug file so kstrtoint() fails.
5. Continue the loop to leak kernel memory on each failed write.
6. Trigger memory pressure, service degradation, system instability, reboot, or kernel panic.

How to detect it

To assess possible prior exploitation, review Linux audit logs, shell histories, endpoint telemetry, and process accounting for repeated writes to MediaTek SVS debugfs files under /sys/kernel/debug. Enable or query auditd rules that monitor write access to /sys/kernel/debug, especially paths containing svs. Look for scripts or command loops using echo, printf, dd, sh, bash, busybox, python, or perl to write non-numeric values to SVS enable controls. Correlate suspicious write activity with kernel logs showing memory pressure, allocation failures, OOM killer events, hung tasks, watchdog resets, or unexpected reboots. On embedded or Android-derived systems, also review persistent kernel logs, pstore/ramoops, dmesg snapshots, logcat kernel buffers, and vendor crash dumps for out-of-memory conditions near the time of local debugfs writes. There are no known remote network indicators for this vulnerability because exploitation is local and file-interface based.

• /sys/kernel/debug/svs
• /sys/kernel/debug/*svs*
• svs_enable_debug_write
• memdup_user_nul
• kstrtoint
• echo * > /sys/kernel/debug/*svs*
• printf * > /sys/kernel/debug/*svs*
• dd of=/sys/kernel/debug/*svs*
• Out of memory: Killed process
• oom-killer
• page allocation failure
• Memory allocation failure
• watchdog: BUG: soft lockup
• Kernel panic - not syncing
• pstore
• ramoops

What your security team should do

• Inventory Linux systems and embedded devices using MediaTek SoCs or kernels with the MediaTek SVS driver enabled.
• Prioritize patching affected MediaTek-based production, shared-user, edge, appliance, and kiosk systems where local users or applications may access debugfs.
• Apply the vendor or distribution kernel update containing the SVS memory leak fix and reboot into the patched kernel.
• Disable or restrict debugfs on production systems; ensure /sys/kernel/debug is not writable by untrusted users, services, containers, or application sandboxes.
• Review kernel build profiles and remove CONFIG_DEBUG_FS from production images unless there is a clear operational requirement.
• Monitor for abnormal local write activity to MediaTek SVS debug files and for unexplained kernel memory exhaustion, OOM activity, or watchdog resets.
• Because EPSS is very low, the issue is not in KEV, and no public mature exploit is reported, schedule remediation according to normal kernel maintenance unless local debug interfaces are exposed to untrusted actors.