CVE-2023-53589
published 2025-10-04CVE-2023-53589: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a corrupted…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.22%
12.2th percentile
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't trust firmware n_channels
If the firmware sends us a corrupted MCC response with
n_channels much larger than the command response can be,
we might copy far too much (uninitialized) memory and
even crash if the n_channels is large enough to make it
run out of the one page allocated for the FW response.
Fix that by checking the lengths. Doing a < comparison
would be sufficient, but the firmware should be doing
it correctly, so check more strictly.
Affected
19 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 | >= dcaf9f5ecb6f395152609bdc40660d9b593dca63 < e519a404a5bbba37693cb10fa61794a5fce4fd9b | e519a404a5bbba37693cb10fa61794a5fce4fd9b |
| linux | linux | >= dcaf9f5ecb6f395152609bdc40660d9b593dca63 < d0d39bed9e95f27a246be91c5929254ac043ed30 | d0d39bed9e95f27a246be91c5929254ac043ed30 |
| linux | linux | >= dcaf9f5ecb6f395152609bdc40660d9b593dca63 < 05ad5a4d421ce65652fcb24d46b7e273130240d6 | 05ad5a4d421ce65652fcb24d46b7e273130240d6 |
| linux | linux | >= dcaf9f5ecb6f395152609bdc40660d9b593dca63 < 557ba100d8cf3661ff8d71c0b4a2cba8db555ec2 | 557ba100d8cf3661ff8d71c0b4a2cba8db555ec2 |
| linux | linux | >= dcaf9f5ecb6f395152609bdc40660d9b593dca63 < c176f03350954b795322de0bfe1d7b514db41f45 | c176f03350954b795322de0bfe1d7b514db41f45 |
| linux | linux | >= dcaf9f5ecb6f395152609bdc40660d9b593dca63 < 682b6dc29d98e857e6ca4bbc077c7dc2899b7473 | 682b6dc29d98e857e6ca4bbc077c7dc2899b7473 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| 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 | >= 4.1 < 5.4.244 | 5.4.244 |
| linux | linux_kernel | >= 5.11 < 5.15.113 | 5.15.113 |
| linux | linux_kernel | >= 5.16 < 6.1.30 | 6.1.30 |
| linux | linux_kernel | >= 5.5 < 5.10.181 | 5.10.181 |
| linux | linux_kernel | >= 6.2 < 6.3.4 | 6.3.4 |
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.
GHSA
GHSA-fh27-hfj9-ccqv: In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't trust firmware n_channels
If the firmware sends us a c
ghsa_unreviewed·2025-10-04
CVE-2023-53589 [MEDIUM] GHSA-fh27-hfj9-ccqv: In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't trust firmware n_channels
If the firmware sends us a c
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't trust firmware n_channels
If the firmware sends us a corrupted MCC response with
n_channels much larger than the command response can be,
we might copy far too much (uninitialized) memory and
even crash if the n_channels is large enough to make it
run out of the one page allocated for the FW response.
Fix that by checking the lengths. Doing a < comparison
would be sufficient, but the firmware should be doing
it correctly, so check more strictly.
OSV
CVE-2023-53589: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a cor
osv·2025-10-04·CVSS 5.5
CVE-2023-53589 [MEDIUM] CVE-2023-53589: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a cor
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response. Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictly.
Red Hat
kernel: wifi: iwlwifi: mvm: don't trust firmware n_channels
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2023-53589 [MEDIUM] CWE-131 kernel: wifi: iwlwifi: mvm: don't trust firmware n_channels
kernel: wifi: iwlwifi: mvm: don't trust firmware n_channels
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't trust firmware n_channels
If the firmware sends us a corrupted MCC response with
n_channels much larger than the command response can be,
we might copy far too much (uninitialized) memory and
even crash if the n_channels is large enough to make it
run out of the one page allocated for the FW response.
Fix that by checking the lengths. Doing a < comparison
would be sufficient, but the firmware should be doing
it correctly, so check more strictly.
Statement: The iwlwifi MVM driver trusted the firmware-reported n_channels in the MCC response and could memcpy past the actual response buffer, leading to out-of-bounds reads and a potential ke
Debian
CVE-2023-53589: linux - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwi...
vendor_debian·2023·CVSS 5.5
CVE-2023-53589 [MEDIUM] CVE-2023-53589: linux - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwi...
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response. Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictly.
Scope: local
bookworm: resolved (fixed in 6.1.37-1)
bullseye: resolved (fixed in 5.10.191-1)
forky: resolved (fixed in 6.3.7-1)
sid: resolved (fixed in 6.3.7-1)
trixie: resolved (fixed in 6.3.7-1)
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/05ad5a4d421ce65652fcb24d46b7e273130240d6https://git.kernel.org/stable/c/557ba100d8cf3661ff8d71c0b4a2cba8db555ec2https://git.kernel.org/stable/c/682b6dc29d98e857e6ca4bbc077c7dc2899b7473https://git.kernel.org/stable/c/c176f03350954b795322de0bfe1d7b514db41f45https://git.kernel.org/stable/c/d0d39bed9e95f27a246be91c5929254ac043ed30https://git.kernel.org/stable/c/e519a404a5bbba37693cb10fa61794a5fce4fd9b
2025-10-04
Published