CVE-2026-98830: wifi: wfx: validate MIB read length before copying to caller
In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: validate MIB read length before copying to caller
wfxhifreadmib() copies reply->length bytes from the firmware response into the caller-provided buffer without checking that reply->length does not exceed vallen. A firmware response with a length field larger than expected overruns the caller buffer and reads past the end of the reply allocation.
Replace the dead -ENOMEM check with an active validation that reply->length fits within vallen before the memcpy.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Compensating control
In wfx_hif_read_mib(), validate that the firmware response field reply->length does not exceed val_len before copying reply->length bytes with memcpy; replace the dead -ENOMEM check with this active length validation.
Event History
Frequently Asked Questions
What must an attacker control to trigger this issue?
The issue requires a firmware response whose length field is larger than the buffer length expected by the caller. The provided data does not establish how an attacker could cause or control such a firmware response.
What is the impact of a malformed firmware response?
The driver can copy more data than the caller-provided buffer can hold, overrunning that buffer. It can also read beyond the end of the firmware reply allocation during the copy.
How is the issue addressed by the fix?
The fix validates that the firmware response length fits within val_len before performing the memcpy. This replaces a dead -ENOMEM check with an active bounds check.