CVE-2026-90244: iommu/dma: Restore locking around msi_page_list

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

iommu/dma: Restore locking around msipagelist

Unlike a group's default domain, which is always freshly allocated and privately owned (iommugroupallocdefaultdomain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommuops and cache-coherency enforcement match.

iommudmagetmsipage() only asserts the caller's own group mutex is held (iommugroupmutexassert()). On an IOMMU that publishes IOMMURESVSWMSI, e.g. ARM SMMU, a VM with two such devices assigned through the legacy container can have their guest drivers probe and allocate MSIs in parallel; each host-side VFIODEVICESETIRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommudmagetmsipage() concurrently and corrupt msipagelist.

commit 288683c92b1a ("iommu: Make iommudmapreparemsi() into a generic operation") dropped the prior msipreparelock on the reasoning that "each iommudomain is unique to a group," which holds for default domains but not this VFIO type1 case. Restore the static lock, since it's only guarding a corner case and will likely never be contended.

iommufd avoids the equivalent problem by having its own callers (iommufdswmapmsi()) take a ctx-wide swmsilock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommudmaswmsi() which is outside VFIO's jurisdiction.