fkie_cve-2022-50117
Vulnerability from fkie_nvd
Published
2025-06-18 11:15
Modified
2025-06-18 13:47
Severity ?
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6e97eba8ad8748fabb795cffc5d9e1a7dcfd7367
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/bba6b12d73d36e0ddbc2c3ac5668a667b00d4345
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfio: Split migration ops from main device ops\n\nvfio core checks whether the driver sets some migration op (e.g.\nset_state/get_state) and accordingly calls its op.\n\nHowever, currently mlx5 driver sets the above ops without regards to its\nmigration caps.\n\nThis might lead to unexpected usage/Oops if user space may call to the\nabove ops even if the driver doesn\u0027t support migration. As for example,\nthe migration state_mutex is not initialized in that case.\n\nThe cleanest way to manage that seems to split the migration ops from\nthe main device ops, this will let the driver setting them separately\nfrom the main ops when it\u0027s applicable.\n\nAs part of that, validate ops construction on registration and include a\ncheck for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set\nin migration_flags.\n\nHISI driver was changed as well to match this scheme.\n\nThis scheme may enable down the road to come with some extra group of\nops (e.g. DMA log) that can be set without regards to the other options\nbased on driver caps."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio: Dividir operaciones de migraci\u00f3n de las operaciones del dispositivo principal El n\u00facleo vfio verifica si el controlador establece alguna operaci\u00f3n de migraci\u00f3n (por ejemplo, set_state/get_state) y, en consecuencia, llama a su operaci\u00f3n. Sin embargo, actualmente el controlador mlx5 establece las operaciones anteriores sin tener en cuenta sus l\u00edmites de migraci\u00f3n. Esto puede llevar a un uso inesperado/Oops si el espacio de usuario puede llamar a las operaciones anteriores incluso si el controlador no admite la migraci\u00f3n. Como por ejemplo, el state_mutex de migraci\u00f3n no se inicializa en ese caso. La forma m\u00e1s limpia de gestionar eso parece dividir las operaciones de migraci\u00f3n de las operaciones del dispositivo principal, esto permitir\u00e1 que el controlador las configure por separado de las operaciones principales cuando sea aplicable. Como parte de eso, valide la construcci\u00f3n de las operaciones en el registro e incluya una comprobaci\u00f3n para VFIO_MIGRATION_STOP_COPY ya que la uAPI afirma que debe establecerse en migration_flags. El controlador HISI tambi\u00e9n se cambi\u00f3 para que coincida con este esquema. Este esquema puede permitir en el futuro contar con alg\u00fan grupo adicional de operaciones (por ejemplo, registro DMA) que se pueden configurar sin tener en cuenta las otras opciones en funci\u00f3n de las capacidades del controlador."
    }
  ],
  "id": "CVE-2022-50117",
  "lastModified": "2025-06-18T13:47:40.833",
  "metrics": {},
  "published": "2025-06-18T11:15:41.370",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6e97eba8ad8748fabb795cffc5d9e1a7dcfd7367"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/bba6b12d73d36e0ddbc2c3ac5668a667b00d4345"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.