CVE-2026-80641: wifi: wlcore: enable the right set of ciphers
In the Linux kernel, the following vulnerability has been resolved:
wifi: wlcore: enable the right set of ciphers
The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key")
lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap:
[ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hintsts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xxqueuerecoverywork+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel drivers/net/wireless/ti/wlcore/main.c (wlcore)to a version that resolves this vulnerability.Patch c34dbc5900b0 - Configuration
Always disable IGTK on wl12xx (wlcore) to prevent the decrementing cipher/key behavior and the endless hardware recovery loop described in the logs.
wlcore (TI wl12xx/wl128x firmware/driver) IGTK key support = disabled
Event History
Frequently Asked Questions
Which devices and firmware conditions are implicated?
The issue involves the wlcore Wi-Fi driver’s IGTK firmware-version check. It can affect systems using firmware that is too old, and the description specifically notes that the check failed to account for chips other than wl18xx; wl128x hardware is cited as exhibiting the problem.
How can an administrator recognize the issue on an affected system?
When connecting through NetworkManager to an access point, affected wl128x systems may report failures to set or add keys, followed by wlcore hardware recovery, a hardware restart request, and command execution failures. The example firmware log identifies version Rev 7.3.10.0.142.