fkie_cve-2025-37837
Vulnerability from fkie_nvd
Published
2025-05-09 07:16
Modified
2025-05-12 17:32
Severity ?
Summary
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/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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5584dbf393df509159813645a487b1ef76557722
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/767e22001dfce64cc03b7def1562338591ab6031
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e38ed6908080047d8fa1763d1da86b584f9eb55b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e5dd974d6e00704553308ef1a88659f8dcfb39d4
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/tegra241-cmdqv: Se corrigen las advertencias debido a dmam_free_coherent() Se observan dos ADVERTENCIAS cuando el controlador SMMU se revierte tras un error: arm-smmu-v3.9.auto: No se pudo registrar iommu arm-smmu-v3.9.auto: La sonda con el controlador arm-smmu-v3 fall\u00f3 con el error -22 ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 5 PID: 1 en kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8 Rastreo de llamadas: 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 ------------[ cortar aqu\u00ed ]------------ \u00a1128 p\u00e1ginas a\u00fan est\u00e1n en uso! ADVERTENCIA: CPU: 16 PID: 1 en mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8 Rastreo de llamadas: 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 Esto se debe a que devres gestiona la memoria de la cola LVCMDQ, mientras que dmam_free_coherent() se llama en el contexto de devm_action_release(). Jason se\u00f1al\u00f3 que \"arm_smmu_impl_probe() ha ordenado incorrectamente las devoluciones de llamada de devres si ops-\u0026gt;device_remove() va a liberar manualmente los recursos asignados por la sonda\": https://lore.kernel.org/linux-iommu/20250407174408.GB1722458@nvidia.com/ De hecho, tegra241_cmdqv_init_structures() solo asigna recursos de memoria, lo que significa que cualquier fallo que genere ser\u00eda similar a -ENOMEM, por lo que no tiene sentido recurrir a la rutina SMMU est\u00e1ndar, ya que es probable que la SMMU est\u00e1ndar tampoco asigne memoria. Elimine la parte de desenrollado en tegra241_cmdqv_init_structures() y devuelva un c\u00f3digo de error adecuado para solicitar al controlador SMMU que llame a tegra241_cmdqv_remove() mediante impl_ops-\u0026gt;device_remove(). Luego, elimine tegra241_vintf_free_lvcmdq(), ya que devres se encargar\u00e1 de ello."
    }
  ],
  "id": "CVE-2025-37837",
  "lastModified": "2025-05-12T17:32:52.810",
  "metrics": {},
  "published": "2025-05-09T07:16:04.467",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5584dbf393df509159813645a487b1ef76557722"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/767e22001dfce64cc03b7def1562338591ab6031"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e38ed6908080047d8fa1763d1da86b584f9eb55b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e5dd974d6e00704553308ef1a88659f8dcfb39d4"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.