ghsa-35cf-498m-vj28
Vulnerability from github
Published
2024-08-21 09:31
Modified
2024-09-04 21:30
Details

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

dmaengine: idxd: Let probe fail when workqueue cannot be enabled

The workqueue is enabled when the appropriate driver is loaded and disabled when the driver is removed. When the driver is removed it assumes that the workqueue was enabled successfully and proceeds to free allocations made during workqueue enabling.

Failure during workqueue enabling does not prevent the driver from being loaded. This is because the error path within drv_enable_wq() returns success unless a second failure is encountered during the error path. By returning success it is possible to load the driver even if the workqueue cannot be enabled and allocations that do not exist are attempted to be freed during driver remove.

Some examples of problematic flows: (a)

idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully.

idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().

(b)

idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0.

idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010

Fix the drv_enable_wq() error path by returning the original error that indicates failure of workqueue enabling. This ensures that the probe fails when an error is encountered and the driver remove paths are only attempted when the workqueue was enabled successfully.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2022-48868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-21T07:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Let probe fail when workqueue cannot be enabled\n\nThe workqueue is enabled when the appropriate driver is loaded and\ndisabled when the driver is removed. When the driver is removed it\nassumes that the workqueue was enabled successfully and proceeds to\nfree allocations made during workqueue enabling.\n\nFailure during workqueue enabling does not prevent the driver from\nbeing loaded. This is because the error path within drv_enable_wq()\nreturns success unless a second failure is encountered\nduring the error path. By returning success it is possible to load\nthe driver even if the workqueue cannot be enabled and\nallocations that do not exist are attempted to be freed during\ndriver remove.\n\nSome examples of problematic flows:\n(a)\n\n idxd_dmaengine_drv_probe() -\u003e drv_enable_wq() -\u003e idxd_wq_request_irq():\n In above flow, if idxd_wq_request_irq() fails then\n idxd_wq_unmap_portal() is called on error exit path, but\n drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The\n driver is thus loaded successfully.\n\n idxd_dmaengine_drv_remove()-\u003edrv_disable_wq()-\u003eidxd_wq_unmap_portal()\n Above flow on driver unload triggers the WARN in devm_iounmap() because\n the device resource has already been removed during error path of\n drv_enable_wq().\n\n(b)\n\n idxd_dmaengine_drv_probe() -\u003e drv_enable_wq() -\u003e idxd_wq_request_irq():\n In above flow, if idxd_wq_request_irq() fails then\n idxd_wq_init_percpu_ref() is never called to initialize the percpu\n counter, yet the driver loads successfully because drv_enable_wq()\n returns 0.\n\n idxd_dmaengine_drv_remove()-\u003e__idxd_wq_quiesce()-\u003epercpu_ref_kill():\n Above flow on driver unload triggers a BUG when attempting to drop the\n initial ref of the uninitialized percpu ref:\n BUG: kernel NULL pointer dereference, address: 0000000000000010\n\nFix the drv_enable_wq() error path by returning the original error that\nindicates failure of workqueue enabling. This ensures that the probe\nfails when an error is encountered and the driver remove paths are only\nattempted when the workqueue was enabled successfully.",
  "id": "GHSA-35cf-498m-vj28",
  "modified": "2024-09-04T21:30:31Z",
  "published": "2024-08-21T09:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48868"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0f150134dd795ffcd60b798a85ab737d8d010fb7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/99dc4520b74e7ca8e9dc9abe37a0b10b49467960"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/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.


Loading…

Loading…

Loading…

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.