CVE-2023-53641
published 2025-10-07CVE-2023-53641: 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…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.15%
4.3th percentile
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
21 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.37-1 (bookworm) | linux 6.1.37-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= fb9987d0f748c983bb795a86f47522313f701a08 < 6719e3797ec52cd144c8a5ba8aaab36674800585 | 6719e3797ec52cd144c8a5ba8aaab36674800585 |
| linux | linux | >= fb9987d0f748c983bb795a86f47522313f701a08 < d9899318660791141ea6002fda5577b2c5d7386e | d9899318660791141ea6002fda5577b2c5d7386e |
| linux | linux | >= fb9987d0f748c983bb795a86f47522313f701a08 < 320d760a35273aa815d58b57e4fd9ba5279a3489 | 320d760a35273aa815d58b57e4fd9ba5279a3489 |
| linux | linux | >= fb9987d0f748c983bb795a86f47522313f701a08 < 59073060fe0950c6ecbe12bdc06469dcac62128d | 59073060fe0950c6ecbe12bdc06469dcac62128d |
| linux | linux | >= fb9987d0f748c983bb795a86f47522313f701a08 < 9b9356a3014123f0ce4b50d9278c1265173150ab | 9b9356a3014123f0ce4b50d9278c1265173150ab |
| linux | linux | >= fb9987d0f748c983bb795a86f47522313f701a08 < f0931fc8f4b6847c72e170d2326861c0a081d680 | f0931fc8f4b6847c72e170d2326861c0a081d680 |
| linux | linux | >= fb9987d0f748c983bb795a86f47522313f701a08 < 8f02d538878c9b1501f624595eb22ee4e5e0ff84 | 8f02d538878c9b1501f624595eb22ee4e5e0ff84 |
| linux | linux | >= fb9987d0f748c983bb795a86f47522313f701a08 < 7654cc03eb699297130b693ec34e25f77b17c947 | 7654cc03eb699297130b693ec34e25f77b17c947 |
| linux | linux_kernel | >= 0 < 5.10.191-1 | 5.10.191-1 |
| linux | linux_kernel | >= 0 < 6.1.37-1 | 6.1.37-1 |
| linux | linux_kernel | >= 0 < 6.3.7-1 | 6.3.7-1 |
| linux | linux_kernel | >= 0 < 6.3.7-1 | 6.3.7-1 |
| linux | linux_kernel | >= 2.6.35 < 4.19.283 | 4.19.283 |
| linux | linux_kernel | >= 4.20 < 5.4.243 | 5.4.243 |
| linux | linux_kernel | >= 5.11 < 5.15.111 | 5.15.111 |
| linux | linux_kernel | >= 5.16 < 6.1.28 | 6.1.28 |
| linux | linux_kernel | >= 5.5 < 5.10.180 | 5.10.180 |
| linux | linux_kernel | >= 6.2 < 6.2.15 | 6.2.15 |
| linux | linux_kernel | >= 6.3 < 6.3.2 | 6.3.2 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: wifi: ath9k: hif_usb: fix memory leak of remain_skbs
vendor_redhat·2025-10-07·CVSS 5.5
CVE-2023-53641 [MEDIUM] CWE-772 kernel: wifi: ath9k: hif_usb: fix memory leak of remain_skbs
kernel: wifi: ath9k: hif_usb: fix memory leak of remain_skbs
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 d
Debian
CVE-2023-53641: linux - In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k...
vendor_debian·2023·CVSS 5.5
CVE-2023-53641 [MEDIUM] CVE-2023-53641: linux - In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k...
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 allo
GHSA
GHSA-hh9m-7vg3-wpg4: 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 allo
ghsa_unreviewed·2025-10-07
CVE-2023-53641 [MEDIUM] CWE-401 GHSA-hh9m-7vg3-wpg4: 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 allo
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
OSV
CVE-2023-53641: 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 alloca
osv·2025-10-07·CVSS 5.5
CVE-2023-53641 [MEDIUM] CVE-2023-53641: 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 alloca
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 allo
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/320d760a35273aa815d58b57e4fd9ba5279a3489https://git.kernel.org/stable/c/59073060fe0950c6ecbe12bdc06469dcac62128dhttps://git.kernel.org/stable/c/6719e3797ec52cd144c8a5ba8aaab36674800585https://git.kernel.org/stable/c/7654cc03eb699297130b693ec34e25f77b17c947https://git.kernel.org/stable/c/8f02d538878c9b1501f624595eb22ee4e5e0ff84https://git.kernel.org/stable/c/9b9356a3014123f0ce4b50d9278c1265173150abhttps://git.kernel.org/stable/c/d9899318660791141ea6002fda5577b2c5d7386ehttps://git.kernel.org/stable/c/f0931fc8f4b6847c72e170d2326861c0a081d680
2025-10-07
Published