linux-cve-announce - CVE-2025-38062: genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025061835-CVE-2025-38062-f2b5@gregkh>
Date: Wed, 18 Jun 2025 11:33:57 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38062: genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie

The IOMMU translation for MSI message addresses has been a 2-step process,
separated in time:

 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address
    is stored in the MSI descriptor when an MSI interrupt is allocated.

 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a
    translated message address.

This has an inherent lifetime problem for the pointer stored in the cookie
that must remain valid between the two steps. However, there is no locking
at the irq layer that helps protect the lifetime. Today, this works under
the assumption that the iommu domain is not changed while MSI interrupts
being programmed. This is true for normal DMA API users within the kernel,
as the iommu domain is attached before the driver is probed and cannot be
changed while a driver is attached.

Classic VFIO type1 also prevented changing the iommu domain while VFIO was
running as it does not support changing the "container" after starting up.

However, iommufd has improved this so that the iommu domain can be changed
during VFIO operation. This potentially allows userspace to directly race
VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and
VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).

This potentially causes both the cookie pointer and the unlocked call to
iommu_get_domain_for_dev() on the MSI translation path to become UAFs.

Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA
address is already known during iommu_dma_prepare_msi() and cannot change.
Thus, it can simply be stored as an integer in the MSI descriptor.

The other UAF related to iommu_get_domain_for_dev() will be addressed in
patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by
using the IOMMU group mutex.

The Linux kernel CVE team has assigned CVE-2025-38062 to this issue.

Affected and fixed versions
===========================

	Fixed in 6.1.141 with commit e4d3763223c7b72ded53425207075e7453b4e3d5
	Fixed in 6.6.93 with commit ba41e4e627db51d914444aee0b93eb67f31fa330
	Fixed in 6.12.31 with commit 53f42776e435f63e5f8e61955e4c205dbfeaf524
	Fixed in 6.14.9 with commit 856152eb91e67858a09e30a7149a1f29b04b7384
	Fixed in 6.15 with commit 1f7df3a691740a7736bbc99dc4ed536120eb4746

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-38062
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	drivers/iommu/dma-iommu.c
	include/linux/msi.h

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/e4d3763223c7b72ded53425207075e7453b4e3d5
	https://git.kernel.org/stable/c/ba41e4e627db51d914444aee0b93eb67f31fa330
	https://git.kernel.org/stable/c/53f42776e435f63e5f8e61955e4c205dbfeaf524
	https://git.kernel.org/stable/c/856152eb91e67858a09e30a7149a1f29b04b7384
	https://git.kernel.org/stable/c/1f7df3a691740a7736bbc99dc4ed536120eb4746