ghsa-hh9m-7vg3-wpg4
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: hif_usb: fix memory leak of remain_skbs
hif_dev->remain_skb is allocated and used exclusively in ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is processed and subsequently freed (in error paths) only during the next call of ath9k_hif_usb_rx_stream().
So, if the urbs are deallocated between those two calls due to the device deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream() is not called next time and the allocated remain_skb is leaked. Our local Syzkaller instance was able to trigger that.
remain_skb makes sense when receiving two consecutive urbs which are logically linked together, i.e. a specific data field from the first skb indicates a cached skb to be allocated, memcpy'd with some data and subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs deallocation supposedly makes that link irrelevant so we need to free the cached skb in those cases.
Fix the leak by introducing a function to explicitly free remain_skb (if it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL when it has not been allocated at all (hif_dev struct is kzalloced) or when it has been processed in next call to ath9k_hif_usb_rx_stream().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
{
"affected": [],
"aliases": [
"CVE-2023-53641"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:47Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: hif_usb: fix memory leak of remain_skbs\n\nhif_dev-\u003eremain_skb is allocated and used exclusively in\nath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is\nprocessed and subsequently freed (in error paths) only during the next\ncall of ath9k_hif_usb_rx_stream().\n\nSo, if the urbs are deallocated between those two calls due to the device\ndeinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()\nis not called next time and the allocated remain_skb is leaked. Our local\nSyzkaller instance was able to trigger that.\n\nremain_skb makes sense when receiving two consecutive urbs which are\nlogically linked together, i.e. a specific data field from the first skb\nindicates a cached skb to be allocated, memcpy\u0027d with some data and\nsubsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs\ndeallocation supposedly makes that link irrelevant so we need to free the\ncached skb in those cases.\n\nFix the leak by introducing a function to explicitly free remain_skb (if\nit is not NULL) when the rx urbs have been deallocated. remain_skb is NULL\nwhen it has not been allocated at all (hif_dev struct is kzalloced) or\nwhen it has been processed in next call to ath9k_hif_usb_rx_stream().\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.",
"id": "GHSA-hh9m-7vg3-wpg4",
"modified": "2025-10-07T18:31:09Z",
"published": "2025-10-07T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53641"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/320d760a35273aa815d58b57e4fd9ba5279a3489"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59073060fe0950c6ecbe12bdc06469dcac62128d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6719e3797ec52cd144c8a5ba8aaab36674800585"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7654cc03eb699297130b693ec34e25f77b17c947"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f02d538878c9b1501f624595eb22ee4e5e0ff84"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b9356a3014123f0ce4b50d9278c1265173150ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9899318660791141ea6002fda5577b2c5d7386e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0931fc8f4b6847c72e170d2326861c0a081d680"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.