Answer in brief
CVE-2026-64117 records a Unknown severity vulnerability in wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3468e1e0c639032a603450f0830ccabfa76f5806 <2fb64f94f9afb774f2fa0c7835727d7a67f89f07 || >=3468e1e0c639032a603450f0830ccabfa76f5806 <d71c841be5d9e586ee7f36c0dc8ed4db0d9a1349 | 2fb64f94f9afb774f2fa0c7835727d7a67f89f07, d71c841be5d9e586ee7f36c0dc8ed4db0d9a1349 |
| Linux/Linuxgeneric | 6.4 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb ieee80211_invoke_fast_rx() reads RX status through IEEE80211_SKB_RXCB(skb), which aliases the same skb->cb storage that ieee80211_rx_mesh_data() reuses as IEEE80211_TX_INFO. In the unicast forward path, mesh_data does: info = IEEE80211_SKB_CB(fwd_skb); memset(info, 0, sizeof(*info)); on the same skb the caller still names via rx->skb, then either queues the skb for TX (success) or kfree_skb()'s it (no-route) before returning RX_QUEUED. The caller's RX_QUEUED arm then calls sta_stats_encode_rate(status) on memory that is either zeroed (success path) or freed (no-route path). The latter is KASAN slab-use-after-free in ieee80211_prepare_and_rx_handle. Fix by encoding the rate from status before invoking ieee80211_rx_mesh_data(), so the RX_QUEUED arm consumes a value captured while status was still backed by valid memory.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-64117 records a Unknown severity vulnerability in wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3468e1e0c639032a603450f0830ccabfa76f5806 <2fb64f94f9afb774f2fa0c7835727d7a67f89f07 || >=3468e1e0c639032a603450f0830ccabfa76f5806 <d71c841be5d9e586ee7f36c0dc8ed4db0d9a1349 | 2fb64f94f9afb774f2fa0c7835727d7a67f89f07, d71c841be5d9e586ee7f36c0dc8ed4db0d9a1349 |
| Linux/Linuxgeneric | 6.4 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb ieee80211_invoke_fast_rx() reads RX status through IEEE80211_SKB_RXCB(skb), which aliases the same skb->cb storage that ieee80211_rx_mesh_data() reuses as IEEE80211_TX_INFO. In the unicast forward path, mesh_data does: info = IEEE80211_SKB_CB(fwd_skb); memset(info, 0, sizeof(*info)); on the same skb the caller still names via rx->skb, then either queues the skb for TX (success) or kfree_skb()'s it (no-route) before returning RX_QUEUED. The caller's RX_QUEUED arm then calls sta_stats_encode_rate(status) on memory that is either zeroed (success path) or freed (no-route path). The latter is KASAN slab-use-after-free in ieee80211_prepare_and_rx_handle. Fix by encoding the rate from status before invoking ieee80211_rx_mesh_data(), so the RX_QUEUED arm consumes a value captured while status was still backed by valid memory.
Quoted source text, attributed separately from HOL analysis.