CVE-2025-37837 in Linux
Summary
by MITRE • 05/09/2025
In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Fix warnings due to dmam_free_coherent()
Two WARNINGs are observed when SMMU driver rolls back upon failure: arm-smmu-v3.9.auto: Failed to register iommu arm-smmu-v3.9.auto: probe with driver arm-smmu-v3 failed with error -22 ------------[ cut here ]------------
WARNING: CPU: 5 PID: 1 at kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8 Call trace: dmam_free_coherent+0xc0/0xd8 (P) tegra241_vintf_free_lvcmdq+0x74/0x188 tegra241_cmdqv_remove_vintf+0x60/0x148 tegra241_cmdqv_remove+0x48/0xc8 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40 ------------[ cut here ]------------
128 pages are still in use! WARNING: CPU: 16 PID: 1 at mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8 Call trace: free_contig_range+0x18c/0x1c8 (P) cma_release+0x154/0x2f0 dma_free_contiguous+0x38/0xa0 dma_direct_free+0x10c/0x248 dma_free_attrs+0x100/0x290 dmam_free_coherent+0x78/0xd8 tegra241_vintf_free_lvcmdq+0x74/0x160 tegra241_cmdqv_remove+0x98/0x198 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40
This is because the LVCMDQ queue memory are managed by devres, while that dmam_free_coherent() is called in the context of devm_action_release().
Jason pointed out that "arm_smmu_impl_probe() has mis-ordered the devres callbacks if ops->device_remove() is going to be manually freeing things that probe allocated": https://lore.kernel.org/linux-iommu/[email protected]/
In fact, tegra241_cmdqv_init_structures() only allocates memory resources which means any failure that it generates would be similar to -ENOMEM, so there is no point in having that "falling back to standard SMMU" routine, as the standard SMMU would likely fail to allocate memory too.
Remove the unwind part in tegra241_cmdqv_init_structures(), and return a proper error code to ask SMMU driver to call tegra241_cmdqv_remove() via impl_ops->device_remove(). Then, drop tegra241_vintf_free_lvcmdq() since devres will take care of that.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/15/2025
The vulnerability described in CVE-2025-37837 affects the Linux kernel's IOMMU implementation, specifically within the Tegra241 command queue virtualization driver. This issue manifests as kernel warnings during SMMU driver rollback operations when device removal fails, indicating improper memory management during driver initialization and cleanup phases. The problem occurs in the arm-smmu-v3 driver context where the system attempts to register an IOMMU device but fails with error code -22, which corresponds to EINVAL or invalid argument errors in kernel space operations.
The technical flaw stems from improper ordering of device resource management callbacks within the driver's probe and remove functions. When the Tegra241 command queue virtualization driver attempts to initialize its structures, it allocates memory resources using devres management, but the cleanup process in the remove function incorrectly calls dmam_free_coherent() directly within the devm_action_release context. This creates a race condition where memory allocated through devres management is attempted to be freed twice, leading to kernel warnings about pages still being in use and memory allocation failures.
The operational impact of this vulnerability extends beyond simple warning messages, as it can cause system instability during driver initialization and removal phases. The improper error handling in the device removal path prevents proper cleanup of allocated memory resources, potentially leading to memory leaks and system hangs. The vulnerability specifically affects systems using Tegra241-based SoCs with SMMUv3 IOMMU implementations, where the driver attempts to manage command queue memory structures through devres while simultaneously handling manual memory cleanup operations. This creates a scenario where the device removal process fails to properly release all allocated resources, as indicated by the "128 pages are still in use!" warning message.
The root cause identified by the kernel developers relates to misordered devres callbacks, where the driver's implementation does not properly handle the relationship between device probe and remove operations. The original implementation attempted to fall back to standard SMMU handling in case of allocation failures, but this approach was flawed since the same memory allocation issues would likely affect both the specialized and standard SMMU paths. The fix involves removing the unwind logic in the initialization function and returning proper error codes to ensure the SMMU driver properly calls the device removal function through the implementation operations interface. This approach ensures that devres management handles all memory cleanup operations appropriately without interference from manual memory management calls.
Security implications of this vulnerability are primarily related to system stability and availability rather than direct exploitation. However, the improper memory management could potentially be leveraged in denial-of-service scenarios where repeated driver initialization failures cause system instability. The vulnerability aligns with CWE-459, which describes incomplete cleanup issues in software systems, and could be categorized under ATT&CK technique T1490 for resource hijacking or system instability. The fix ensures proper resource lifecycle management in kernel space, preventing the improper memory release patterns that could lead to system crashes or resource exhaustion in embedded systems using Tegra241-based platforms.