CVE-2026-46255

What it actually does

This is a Linux kernel flaw in the Freescale/NXP eDMA dmaengine driver removal path. The driver obtains and enables mux clocks using devm_clk_get_enabled(), which already registers automatic cleanup, but fsl_edma_remove() also manually disables and unprepares the same clocks. When the fsl-edma driver is removed or the device is unbound, the duplicate cleanup can trigger kernel warnings such as attempts to disable or unprepare an already-disabled clock. The assigned impact is local denial of service: a local user with the ability to trigger driver removal, module unloading, or device unbinding may cause kernel warning conditions and potentially affect system availability depending on kernel panic-on-warn policy, platform configuration, and hardware use of the fsl-edma driver.

Why it matters to the business

Systems using affected Linux kernels with the fsl-edma driver may experience avoidable instability during driver removal, device unbind operations, maintenance, or hardware reconfiguration. The practical risk is highest for embedded, industrial, edge, and appliance-style Linux deployments using Freescale/NXP eDMA hardware, especially where kernel warnings are configured to panic the system. The vulnerability is not known to be remotely exploitable, is not listed in CISA KEV, has very low EPSS, and has no reported exploit maturity, so remediation should be prioritized for exposed affected platforms and scheduled kernel maintenance rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker first needs local access with sufficient privileges or delegated capability to cause the fsl-edma driver to be removed, unloaded, or unbound from its device. The vulnerable removal routine calls fsl_disable_clocks() even though the clocks were allocated through devm-managed APIs that already handle cleanup. This causes the kernel clock framework to receive disable and unprepare operations for clocks that are already disabled or unprepared. The immediate observable result is kernel warning output referencing clk_core_disable(), clk_core_unprepare(), and fsl_edma_remove(). On systems configured to panic on kernel warnings, or where repeated driver removal disrupts DMA-dependent workloads, this can become a local denial-of-service condition.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix removing the unnecessary fsl_disable_clocks() call from fsl_edma_remove(). Because no exact fixed package versions were provided, use your distribution vendor's advisory or kernel changelog to identify a kernel containing the fsl-edma dmaengine fix for this CVE. If immediate patching is not possible, reduce exposure by avoiding unnecessary fsl-edma driver unload/reload operations, restricting administrative access to module management and sysfs device unbind interfaces, disabling unprivileged module loading where applicable, and ensuring kernel panic-on-warn settings are appropriate for the operational environment. Systems that do not include or load the fsl-edma driver, or do not run on hardware using that driver, are unlikely to be affected in practice.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build or upstream commit containing the fsl-edma removal-path fix. Verify whether the fsl_edma module is present or loaded using tools such as lsmod, modinfo, /proc/modules, and kernel configuration checks. On representative non-production hardware, validate that removing or unbinding the fsl-edma device no longer produces warnings containing 'edma_module already disabled', 'edma_module already unprepared', 'clk_core_disable', 'clk_core_unprepare', or 'fsl_edma_remove'. Review dmesg, journald, and persistent kernel logs after upgrade to confirm the warnings no longer occur during driver removal or maintenance operations.

Typical attack path

1. Gain local access to a Linux system running an affected kernel on hardware using the fsl-edma dmaengine driver.
2. Obtain or abuse privileges sufficient to unload the fsl_edma module, unbind the platform device, or otherwise trigger the driver's remove path.
3. Trigger removal of the fsl-edma driver or associated device.
4. The vulnerable fsl_edma_remove() routine manually disables clocks that are also devm-managed.
5. The kernel emits warnings for already-disabled or already-unprepared clocks; on hardened configurations such as panic_on_warn, the system may crash or become unavailable.

How to detect it

To determine whether this condition has already been triggered, review kernel log sources including dmesg output, journald kernel facility logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, pstore/ramoops records, and centralized SIEM copies of host kernel logs. Look for warnings during module removal, device unbinding, shutdown, reboot, or hardware maintenance involving the fsl-edma driver. Key artifacts include warning traces mentioning 'edma_module already disabled', 'edma_module already unprepared', 'clk_core_disable', 'clk_core_unprepare', and 'fsl_edma_remove'. Also correlate events with commands or audit records for rmmod, modprobe -r, driver unbind writes under /sys/bus/*/drivers/*/unbind, or service automation that reloads kernel modules. There are no known public threat actors or ransomware campaigns associated with this issue, and exploitation requires local ability to trigger driver removal, so investigation should focus on administrative activity, maintenance automation, and unexpected local privilege use rather than remote network indicators.

• edma_module already disabled
• edma_module already unprepared
• WARNING: CPU:
• clk_core_disable
• clk_core_unprepare
• clk_disable
• clk_unprepare
• fsl_edma_remove
• [fsl_edma]
• drivers/clk/clk.c:1200
• drivers/clk/clk.c:1059
• ---[ end trace
• /sys/bus/platform/drivers/fsl-edma/unbind
• rmmod fsl_edma
• modprobe -r fsl_edma

What your security team should do

• Inventory Linux systems using Freescale/NXP eDMA hardware or loading the fsl_edma driver, prioritizing embedded, industrial, appliance, and edge devices.
• Apply the vendor-provided kernel update containing the fsl-edma dmaengine fix during the next appropriate maintenance window, with higher priority for systems configured with panic_on_warn or requiring high availability.
• Restrict access to kernel module loading/unloading and sysfs driver unbind controls to trusted administrators only.
• Search historical kernel logs for the warning strings associated with this flaw to identify prior triggering events or unstable maintenance procedures.
• If kernel warnings cause panics in production, review panic_on_warn and related hardening settings against availability requirements while still preserving security monitoring.
• For systems not using fsl-edma hardware, document non-applicability rather than performing emergency remediation.