ghsa-wgf9-7m97-x4xg
Vulnerability from github
Published
2024-05-21 18:31
Modified
2024-07-03 18:42
Severity ?
6.2 (Medium) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Details

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

mfd: qcom-spmi-pmic: Fix revid implementation

The Qualcomm SPMI PMIC revid implementation is broken in multiple ways.

First, it assumes that just because the sibling base device has been registered that means that it is also bound to a driver, which may not be the case (e.g. due to probe deferral or asynchronous probe). This could trigger a NULL-pointer dereference when attempting to access the driver data of the unbound device.

Second, it accesses driver data of a sibling device directly and without any locking, which means that the driver data may be freed while it is being accessed (e.g. on driver unbind).

Third, it leaks a struct device reference to the sibling device which is looked up using the spmi_device_from_of() every time a function (child) device is calling the revid function (e.g. on probe).

Fix this mess by reimplementing the revid lookup so that it is done only at probe of the PMIC device; the base device fetches the revid info from the hardware, while any secondary SPMI device fetches the information from the base device and caches it so that it can be accessed safely from its children. If the base device has not been probed yet then probe of a secondary device is deferred.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-52765"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T16:15:15Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmfd: qcom-spmi-pmic: Fix revid implementation\n\nThe Qualcomm SPMI PMIC revid implementation is broken in multiple ways.\n\nFirst, it assumes that just because the sibling base device has been\nregistered that means that it is also bound to a driver, which may not\nbe the case (e.g. due to probe deferral or asynchronous probe). This\ncould trigger a NULL-pointer dereference when attempting to access the\ndriver data of the unbound device.\n\nSecond, it accesses driver data of a sibling device directly and without\nany locking, which means that the driver data may be freed while it is\nbeing accessed (e.g. on driver unbind).\n\nThird, it leaks a struct device reference to the sibling device which is\nlooked up using the spmi_device_from_of() every time a function (child)\ndevice is calling the revid function (e.g. on probe).\n\nFix this mess by reimplementing the revid lookup so that it is done only\nat probe of the PMIC device; the base device fetches the revid info from\nthe hardware, while any secondary SPMI device fetches the information\nfrom the base device and caches it so that it can be accessed safely\nfrom its children. If the base device has not been probed yet then probe\nof a secondary device is deferred.",
  "id": "GHSA-wgf9-7m97-x4xg",
  "modified": "2024-07-03T18:42:53Z",
  "published": "2024-05-21T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52765"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4ce77b023d42a9f1062eecf438df1af4b4072eb2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7b439aaa62fee474a0d84d67a25f4984467e7b95"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/affae18838db5e6b463ee30c821385695af56dc2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/db98de0809f12b0edb9cd1be78e1ec1bfeba8f40"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/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.