GHSA-6GG5-JM4H-XVVC
Vulnerability from github – Published: 2026-08-28 09:31 – Updated: 2026-08-28 09:31In 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, hint_sts: 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 wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess.
{
"affected": [],
"aliases": [
"CVE-2026-80641"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-28T08:16:49Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wlcore: enable the right set of ciphers\n\nThe firmware version number check for IGTK introduced in\ncommit c34dbc5900b0 (\"wifi: wlcore: Add support for IGTK key\")\n\nlets the amount of ciphers decrease on every boot of a too old firmware and\nthat is practically happening. It also does not take into account other\nchips than the wl18xx. On some wl128x, the following can be observed\nwhen connecting via nm to a common ap:\n\n[ 484.113311] wlcore: WARNING could not set keys\n[ 484.117828] wlcore: ERROR Could not add or replace key\n[ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5)\n[ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142\n[ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1\n[ 484.145721] wlcore: down\n[ 484.148986] ieee80211 phy0: Hardware restart was requested\n[ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142)\n[ 484.633758] wlcore: Association completed.\n[ 484.690490] wlcore: ERROR command execute failure 14\n[ 484.690490] ------------[ cut here ]------------\n[ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892\n\nThis repeats endlessly.\nAlways disable IGTK on wl12xx and fix the decrementing mess.",
"id": "GHSA-6gg5-jm4h-xvvc",
"modified": "2026-08-28T09:31:47Z",
"published": "2026-08-28T09:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80641"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7495adaa0e45e180f4b6b7436675c6266edff1ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff9748200698e9641f41ba922ffef728167807c2"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.