CVE-2025-38062
Analyzed Analyzed - Analysis Complete
BaseFortify

Publication date: 2025-06-18

Last updated on: 2025-12-18

Assigner: kernel.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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-18
Last Modified
2025-12-18
Generated
2026-05-06
AI Q&A
2025-06-18
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38062
Affected Vendors & Products
Showing 5 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.2 (inc) to 6.1.141 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.93 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.31 (exc)
linux linux_kernel From 6.13 (inc) to 6.14.9 (exc)
debian debian_linux 11.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves a use-after-free (UAF) issue in the Linux kernel's handling of MSI (Message Signaled Interrupts) translation with IOMMU (Input-Output Memory Management Unit). Specifically, a pointer (cookie) stored during MSI interrupt allocation can become invalid between two steps of MSI message address translation due to lack of locking and changes in the IOMMU domain during VFIO operation. This can lead to unsafe memory access. The fix involves storing the translated IOVA address directly as an integer instead of a pointer to avoid the UAF.


How can this vulnerability impact me? :

This vulnerability can lead to use-after-free conditions in the kernel, potentially causing system instability, crashes, or security issues such as privilege escalation or arbitrary code execution if exploited. It affects systems using VFIO with iommufd where the IOMMU domain can be changed during operation, allowing a race condition that triggers the vulnerability.


What immediate steps should I take to mitigate this vulnerability?

Apply the patch that fixes the MSI cookie use-after-free (UAF) by storing the translated IOVA address directly as an integer in the MSI descriptor instead of a cookie pointer. Additionally, ensure that the kernel version includes the fix that prevents the race condition by using proper locking mechanisms such as the IOMMU group mutex. Avoid changing the iommu domain during VFIO operation until the patch is applied.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart