In the Linux kernel, the following vulnerability has been resolved: vfio: Split migration ops from main device ops vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op. However, currently mlx5 driver sets the above ops without regards to its migration caps. This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable. As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags. HISI driver was changed as well to match this scheme. This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps.
History

Wed, 02 Jul 2025 02:30:00 +0000

Type Values Removed Values Added
First Time appeared Redhat
Redhat enterprise Linux
Weaknesses CWE-824
CPEs cpe:/a:redhat:enterprise_linux:9
cpe:/o:redhat:enterprise_linux:9
Vendors & Products Redhat
Redhat enterprise Linux

Thu, 19 Jun 2025 15:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Wed, 18 Jun 2025 11:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: vfio: Split migration ops from main device ops vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op. However, currently mlx5 driver sets the above ops without regards to its migration caps. This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable. As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags. HISI driver was changed as well to match this scheme. This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps.
Title vfio: Split migration ops from main device ops
References

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2025-06-18T11:02:47.994Z

Updated: 2025-06-18T11:02:47.994Z

Reserved: 2025-06-18T10:57:27.415Z

Link: CVE-2022-50117

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2025-06-18T11:15:41.370

Modified: 2025-06-18T13:47:40.833

Link: CVE-2022-50117

cve-icon Redhat

Severity : Moderate

Publid Date: 2025-06-18T00:00:00Z

Links: CVE-2022-50117 - Bugzilla