LiveActive security incident?Get immediate response
CVE Record

CVE-2022-50117: vfio: Split migration ops from main device ops

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue affects VFIO device migration handling. A driver could expose migration operations even when migration was not actually supported, allowing user space to trigger unexpected kernel behavior, including an Oops. The sources do not provide a CVSS score, confirmed impact scope, or active exploitation evidence.

Executive priority

Treat this as a targeted kernel reliability and isolation-risk item for virtualization infrastructure. It does not currently justify emergency response based on the supplied evidence, but affected VFIO hosts should be patched through the normal kernel security process.

Technical view

VFIO core called migration callbacks when drivers registered them. The mlx5 driver could register those callbacks without matching migration capability state, leaving migration structures such as state_mutex uninitialized. The fix separates migration ops from main device ops and validates ops registration, also aligning HISI behavior.

Likely exposure

Likely limited to Linux systems using affected kernels and VFIO-capable devices, especially environments involving mlx5 or HISI VFIO migration paths. The bundle lists Linux 5.18 through 5.19.2-era/6.0 affected data, but version boundaries are not fully clear.

Exploitation context

The provided sources do not report active exploitation, public exploit availability, or KEV listing. The described failure mode requires user space reaching VFIO migration operations on a driver without proper migration capability support.

Researcher notes

The source bundle provides a resolved upstream kernel change but no CVSS, CWE, exploit report, or detailed affected-version matrix. Analysis should focus on VFIO migration capability checks, mlx5 registration behavior, HISI alignment, and whether downstream kernels backported the split migration ops fix.

Mitigation direction

  • Review vendor kernel advisories for CVE-2022-50117 and affected package versions.
  • Update to a kernel containing the referenced stable fixes.
  • Prioritize virtualization hosts using VFIO, mlx5, or HISI device assignment paths.
  • If patching is delayed, restrict untrusted access to VFIO device interfaces.
  • Track distribution-specific backports instead of relying only on upstream version numbers.

Validation and detection

  • Inventory kernels running on virtualization and device-passthrough hosts.
  • Check whether VFIO, mlx5, or HISI VFIO drivers are present or loaded.
  • Confirm installed kernel packages include the referenced stable fix commits or vendor backports.
  • Review logs for kernel Oops events involving VFIO migration paths.
  • Validate remediation in staging before production kernel rollout.
Prepared
Confidence
medium
Sources
4

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2022-50117 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
3Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux6fadb021266d03c5fd7bca2cfa1607efd246dad1, 6fadb021266d03c5fd7bca2cfa1607efd246dad1unaffected
LinuxLinux5.18, 0, 5.19.2, 6.0affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.