CVE-2026-98189: wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext()
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: fix RX buffer OOB-write in wilcwlanhandleisrext()
wilcwlanhandleisrext() takes the RX transfer size from the device-reported interrupt status register (a 15-bit field shifted left by 2, up to 131068 bytes) and reads that many bytes from the device into rxbuffer, which is only WILCRXBUFFSIZE (96K) large. The wrap check only handles the current offset; the size itself is never compared against the buffer, so a bogus SDIO device can make the driver OOB-write rxbuffer by up to ~32K with data it controls.
The oversized transfer also leaves rxbufferoffset past the end of the buffer, after which the unsigned wrap check stops working and the overflow can repeat.
Drop any transfer whose size exceeds the RX buffer, acknowledging the data interrupt and re-arming the RX engine so the bogus frame is discarded and reception can continue. This also restores the rxbufferoffset <= WILCRXBUFFSIZE invariant the wrap check relies on.
This is not expected to change driver behavior in most cases: without this check, an oversized transfer would most likely corrupt neighboring kernel memory instead of completing anyway, and the drop path performs the same interrupt acknowledgment and RX engine re-arming as the normal path, so subsequent transfers are received unaffected.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Linux kernel wilc1000 driver, drop any RX transfer whose size exceeds the WILC_RX_BUFF_SIZE (96K) rx_buffer before reading the data, and acknowledge the device-reported interrupt status so reception can continue.
Event History
Frequently Asked Questions
Which deployments are exposed?
Linux systems using the wilc1000 Wi-Fi driver are exposed when the driver processes receive transfers reported by its SDIO device. The issue is triggered by a device-reported receive size larger than the driver's 96K receive buffer.
What does an attacker need to control to exploit this?
An attacker needs control of, or the ability to emulate, a bogus SDIO Wi-Fi device that can report an oversized receive transfer and supply its contents. The reported size can be up to 131,068 bytes, allowing controlled data to be written beyond the receive buffer.
How can I check whether the fix is present?
Check whether the kernel source includes the fix associated with the referenced stable commits 3ddb88e237bc1e59fd37b1cf369f3b6c2dedae26, 9f6a276ade936a8803f9f3df217c2368944dc321, or aeb44a456d126d89863230eef0187e77e6441995. The corrected behavior discards receive transfers whose size exceeds the RX buffer while acknowledging the interrupt and re-arming reception.