CVE-2026-98407: wifi: rsi: fix heap OOB write on key removal
In the Linux kernel, the following vulnerability has been resolved:
wifi: rsi: fix heap OOB write on key removal
When a key is removed (data == NULL), rsihalloadkey() runs:
memset(&setkey[FRAMEDESCSZ], 0, framelen - FRAMEDESCSZ);
setkey is a struct rsisetkey , so the subscript is scaled by sizeof(struct rsisetkey) (160 bytes): &setkey[FRAMEDESCSZ] is skb->data + 2560, and the memset writes 144 zero bytes starting 2.4KB past the end of the 160-byte skb data buffer, corrupting unrelated heap objects. The intended byte offset would have been (u8 )setkey + FRAMEDESCSZ.
The write fires on every DISABLEKEY callback, so plain disconnects, roams and interface teardowns trigger it on real networks.
The memset is redundant: the whole buffer is zeroed right after allocation, so the frame sent to the device is byte-identical without it. Drop the else branch; normal operation is unaffected.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Drop the else branch containing the redundant memset in the RSI Wi-Fi key-removal path; normal operation is unaffected.
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel RSI Wi-Fi driver are exposed when the driver processes key-removal callbacks. The affected path can be reached during normal wireless events including disconnects, roaming, and interface teardown.
Does exploitation require a special or malicious Wi-Fi operation?
No special operation is described. The out-of-bounds heap write fires on every DISABLE_KEY callback, including callbacks produced by ordinary network disconnects, roams, and interface shutdowns.
How can I tell whether the vulnerable path has been triggered?
The provided information does not identify a log message, crash signature, or other reliable indicator. Because the write occurs during normal Wi-Fi lifecycle events, affected systems may trigger it during ordinary disconnect, roaming, or teardown activity.
What is the mitigation if an update cannot be applied immediately?
The data does not provide a tested workaround. Reducing use of the RSI Wi-Fi driver and avoiding the events that invoke DISABLE_KEY callbacks, such as wireless disconnects, roams, and interface teardowns, would reduce exposure but is not a complete mitigation.