CVE-2025-38479 in Linux
Summary
by MITRE • 04/18/2025
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-edma: free irq correctly in remove path
Add fsl_edma->txirq/errirq check to avoid below warning because no errirq at i.MX9 platform. Otherwise there will be kernel dump: WARNING: CPU: 0 PID: 11 at kernel/irq/devres.c:144 devm_free_irq+0x74/0x80 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.12.0-rc7#18 Hardware name: NXP i.MX93 11X11 EVK board (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devm_free_irq+0x74/0x80 lr : devm_free_irq+0x48/0x80 Call trace: devm_free_irq+0x74/0x80 (P) devm_free_irq+0x48/0x80 (L) fsl_edma_remove+0xc4/0xc8 platform_remove+0x28/0x44 device_remove+0x4c/0x80
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/16/2026
This vulnerability exists within the Freescale EDMA (Enhanced Direct Memory Access) driver implementation in the Linux kernel version 6.12.0-rc7 and affects platforms such as the i.MX93 11X11 EVK board. The issue manifests as improper handling of interrupt resources during device removal operations, specifically when the driver attempts to free interrupt lines that were never allocated. The root cause lies in the fsl_edma_remove function which does not properly check whether transmit and error interrupt resources have been successfully acquired before attempting to release them. This oversight occurs particularly on i.MX9 platforms where error interrupts are not implemented, leading to a scenario where the driver attempts to free a non-existent interrupt resource.
The technical flaw represents a classic resource management error that can be categorized under CWE-459, specifically "Incomplete Cleanup," where the driver fails to properly manage dynamically allocated resources. When the platform_remove function is invoked during device unloading, the driver calls devm_free_irq without verifying the existence of the interrupt handles, resulting in a kernel warning message that indicates a critical failure in the interrupt resource management subsystem. The kernel dump shows the error occurring in kernel/irq/devres.c at line 144 within the devm_free_irq function, indicating that the device manager is attempting to free an interrupt that was never properly registered or allocated.
The operational impact of this vulnerability extends beyond simple warning messages to potentially causing system instability and kernel crashes. The improper interrupt handling can lead to resource leaks, memory corruption, or even complete system lockups during device removal sequences. This is particularly concerning in embedded systems where the i.MX9 platform is commonly deployed, as these systems often require reliable interrupt handling for real-time operations and device communication. The vulnerability affects the broader ATT&CK matrix under T1547.001 (Registry Run Keys / Startup Folder) and T1059 (Command and Scripting Interpreter) as it can potentially be exploited to cause system-wide disruptions or create persistent access points through compromised device drivers. The issue becomes more pronounced in environments where multiple device drivers are loaded and unloaded dynamically, as the improper cleanup can cascade into other subsystems.
Mitigation strategies should focus on implementing proper interrupt resource validation before attempting deallocation. The fix requires adding checks for fsl_edma->txirq and fsl_edma->errirq handles before calling devm_free_irq, ensuring that interrupts are only freed when they have been successfully requested. This approach aligns with best practices for device driver development and follows the principle of defensive programming. System administrators should ensure that all kernel updates are applied promptly, particularly when dealing with embedded platforms that utilize the Freescale EDMA driver. The vulnerability demonstrates the importance of proper resource management in kernel space and highlights the need for thorough testing across different hardware platforms, especially when dealing with platform-specific variations in interrupt handling capabilities. Additionally, monitoring systems should be configured to detect and alert on kernel warnings related to interrupt resource management, as these may indicate similar issues in other device drivers within the same kernel subsystem.