ghsa-2862-5xjv-8phr
Vulnerability from github
Published
2024-08-22 06:30
Modified
2024-08-22 21:31
Severity ?
4.7 (Medium) - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Details

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

ice: fix concurrent reset and removal of VFs

Commit c503e63200c6 ("ice: Stop processing VF messages during teardown") introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is intended to prevent some issues with concurrently handling messages from VFs while tearing down the VFs.

This change was motivated by crashes caused while tearing down and bringing up VFs in rapid succession.

It turns out that the fix actually introduces issues with the VF driver caused because the PF no longer responds to any messages sent by the VF during its .remove routine. This results in the VF potentially removing its DMA memory before the PF has shut down the device queues.

Additionally, the fix doesn't actually resolve concurrency issues within the ice driver. It is possible for a VF to initiate a reset just prior to the ice driver removing VFs. This can result in the remove task concurrently operating while the VF is being reset. This results in similar memory corruption and panics purportedly fixed by that commit.

Fix this concurrency at its root by protecting both the reset and removal flows using the existing VF cfg_lock. This ensures that we cannot remove the VF while any outstanding critical tasks such as a virtchnl message or a reset are occurring.

This locking change also fixes the root cause originally fixed by commit c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we can simply revert it.

Note that I kept these two changes together because simply reverting the original commit alone would leave the driver vulnerable to worse race conditions.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-48941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-22T04:15:17Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix concurrent reset and removal of VFs\n\nCommit c503e63200c6 (\"ice: Stop processing VF messages during teardown\")\nintroduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is\nintended to prevent some issues with concurrently handling messages from\nVFs while tearing down the VFs.\n\nThis change was motivated by crashes caused while tearing down and\nbringing up VFs in rapid succession.\n\nIt turns out that the fix actually introduces issues with the VF driver\ncaused because the PF no longer responds to any messages sent by the VF\nduring its .remove routine. This results in the VF potentially removing\nits DMA memory before the PF has shut down the device queues.\n\nAdditionally, the fix doesn\u0027t actually resolve concurrency issues within\nthe ice driver. It is possible for a VF to initiate a reset just prior\nto the ice driver removing VFs. This can result in the remove task\nconcurrently operating while the VF is being reset. This results in\nsimilar memory corruption and panics purportedly fixed by that commit.\n\nFix this concurrency at its root by protecting both the reset and\nremoval flows using the existing VF cfg_lock. This ensures that we\ncannot remove the VF while any outstanding critical tasks such as a\nvirtchnl message or a reset are occurring.\n\nThis locking change also fixes the root cause originally fixed by commit\nc503e63200c6 (\"ice: Stop processing VF messages during teardown\"), so we\ncan simply revert it.\n\nNote that I kept these two changes together because simply reverting the\noriginal commit alone would leave the driver vulnerable to worse race\nconditions.",
  "id": "GHSA-2862-5xjv-8phr",
  "modified": "2024-08-22T21:31:29Z",
  "published": "2024-08-22T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48941"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/05ae1f0fe9c6c5ead08b306e665763a352d20716"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a3e61de89bab6696aa28b70030eb119968c5586"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3c805fce07c9dbc47d8a9129c7c5458025951957"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fadead80fe4c033b5e514fcbadd20b55c4494112"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


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.