8.8 HIGH
- CVSS version (CVSS): 3.1
- Attack Vector (AV): Adjacent (A)
- Attack Complexity (AC): Low (L)
- Privileges Required (PR): None (N)
- User Interaction (UI): None (N)
- Scope (S): Unchanged (U)
- Confidentiality (C): High (H)
- Integrity (I): High (H)
- Availability (A): High (H)
- Modified Attack Vector (MAV): Adjacent (A)
- Modified Attack Complexity (MAC): Low (L)
- Modified Privileges Required (MPR): None (N)
- Modified User Interaction (MUI): None (N)
- Modified Confidentiality (MC): High (H)
- Modified Scope (MS): Unchanged (U)
- Modified Integrity (MI): High (H)
- Modified Availability (MA): High (H)
Activity log
- Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb
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.
References
Affected products
- ==6.4
- =<7.0.*
- <2fb64f94f9afb774f2fa0c7835727d7a67f89f07
- <6.4
- <d71c841be5d9e586ee7f36c0dc8ed4db0d9a1349
- =<*