ghsa-g3jj-jjrf-q5mw
Vulnerability from github
Published
2024-05-01 15:30
Modified
2024-05-01 15:30
Details

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

wifi: wilc1000: do not realloc workqueue everytime an interface is added

Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to set the interface name in the workqueue name. However, while the driver needs only one workqueue, the wilc_netdev_ifc_init is called each time we add an interface over a phy, which in turns overwrite the workqueue with a new one. This can be observed with the following commands:

for i in $(seq 0 10) do iw phy phy0 interface add wlan1 type managed iw dev wlan1 del done ps -eo pid,comm|grep wlan

39 kworker/R-wlan0 98 kworker/R-wlan1 102 kworker/R-wlan1 105 kworker/R-wlan1 108 kworker/R-wlan1 111 kworker/R-wlan1 114 kworker/R-wlan1 117 kworker/R-wlan1 120 kworker/R-wlan1 123 kworker/R-wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1

Fix this leakage by putting back hif_workqueue allocation in wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to set it lowercase, however it is not attached to a specific netdev, so enforcing netdev name in the name is not so relevant. Still, enrich the name with the wiphy name to make it clear which phy is using the workqueue.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-27391"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T13:15:51Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: do not realloc workqueue everytime an interface is added\n\nCommit 09ed8bfc5215 (\"wilc1000: Rename workqueue from \"WILC_wq\" to\n\"NETDEV-wq\"\") moved workqueue creation in wilc_netdev_ifc_init in order to\nset the interface name in the workqueue name. However, while the driver\nneeds only one workqueue, the wilc_netdev_ifc_init is called each time we\nadd an interface over a phy, which in turns overwrite the workqueue with a\nnew one. This can be observed with the following commands:\n\nfor i in $(seq 0 10)\ndo\n  iw phy phy0 interface add wlan1 type managed\n  iw dev wlan1 del\ndone\nps -eo pid,comm|grep wlan\n\n 39 kworker/R-wlan0\n 98 kworker/R-wlan1\n102 kworker/R-wlan1\n105 kworker/R-wlan1\n108 kworker/R-wlan1\n111 kworker/R-wlan1\n114 kworker/R-wlan1\n117 kworker/R-wlan1\n120 kworker/R-wlan1\n123 kworker/R-wlan1\n126 kworker/R-wlan1\n129 kworker/R-wlan1\n\nFix this leakage by putting back hif_workqueue allocation in\nwilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to\nset it lowercase, however it is not  attached to a specific netdev, so\nenforcing netdev name in the name is not so relevant. Still, enrich the\nname with the wiphy name to make it clear which phy is using the workqueue.",
  "id": "GHSA-g3jj-jjrf-q5mw",
  "modified": "2024-05-01T15:30:37Z",
  "published": "2024-05-01T15:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27391"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/328efda22af81130c2ad981c110518cb29ff2f1d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4041c60a9d543b3ad50225385b072ba68e96166e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/515cc676dfbce40d93c92b1ff3c1070e917f4e52"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/90ae293d1d255f622318fce6eeea2e18f9fde5c1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9ab0c303ccabfd6bdce14432792d41090070008c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


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.