GHSA-Q7Q8-5X36-4R88
Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-14 21:30In 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/20250407174408.GB1722458@nvidia.com/
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.
{
"affected": [],
"aliases": [
"CVE-2025-37837"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/tegra241-cmdqv: Fix warnings due to dmam_free_coherent()\n\nTwo WARNINGs are observed when SMMU driver rolls back upon failure:\n arm-smmu-v3.9.auto: Failed to register iommu\n arm-smmu-v3.9.auto: probe with driver arm-smmu-v3 failed with error -22\n ------------[ cut here ]------------\n WARNING: CPU: 5 PID: 1 at kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8\n Call trace:\n dmam_free_coherent+0xc0/0xd8 (P)\n tegra241_vintf_free_lvcmdq+0x74/0x188\n tegra241_cmdqv_remove_vintf+0x60/0x148\n tegra241_cmdqv_remove+0x48/0xc8\n arm_smmu_impl_remove+0x28/0x60\n devm_action_release+0x1c/0x40\n ------------[ cut here ]------------\n 128 pages are still in use!\n WARNING: CPU: 16 PID: 1 at mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8\n Call trace:\n free_contig_range+0x18c/0x1c8 (P)\n cma_release+0x154/0x2f0\n dma_free_contiguous+0x38/0xa0\n dma_direct_free+0x10c/0x248\n dma_free_attrs+0x100/0x290\n dmam_free_coherent+0x78/0xd8\n tegra241_vintf_free_lvcmdq+0x74/0x160\n tegra241_cmdqv_remove+0x98/0x198\n arm_smmu_impl_remove+0x28/0x60\n devm_action_release+0x1c/0x40\n\nThis is because the LVCMDQ queue memory are managed by devres, while that\ndmam_free_coherent() is called in the context of devm_action_release().\n\nJason pointed out that \"arm_smmu_impl_probe() has mis-ordered the devres\ncallbacks if ops-\u003edevice_remove() is going to be manually freeing things\nthat probe allocated\":\nhttps://lore.kernel.org/linux-iommu/20250407174408.GB1722458@nvidia.com/\n\nIn fact, tegra241_cmdqv_init_structures() only allocates memory resources\nwhich means any failure that it generates would be similar to -ENOMEM, so\nthere is no point in having that \"falling back to standard SMMU\" routine,\nas the standard SMMU would likely fail to allocate memory too.\n\nRemove the unwind part in tegra241_cmdqv_init_structures(), and return a\nproper error code to ask SMMU driver to call tegra241_cmdqv_remove() via\nimpl_ops-\u003edevice_remove(). Then, drop tegra241_vintf_free_lvcmdq() since\ndevres will take care of that.",
"id": "GHSA-q7q8-5x36-4r88",
"modified": "2025-11-14T21:30:27Z",
"published": "2025-05-09T09:33:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37837"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5584dbf393df509159813645a487b1ef76557722"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/767e22001dfce64cc03b7def1562338591ab6031"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e38ed6908080047d8fa1763d1da86b584f9eb55b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5dd974d6e00704553308ef1a88659f8dcfb39d4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.