CVE-2022-50880 in Linux
الملخص
بحسب VulDB • 02/06/2026
Based on the kernel log snippet provided, here is an analysis of the issue, its cause, and potential solutions.
### **Summary** This is a **Use-After-Free (UAF)** or **Double-Free** bug in the `ath10k` Wi-Fi driver (specifically the `ath10k_core` module). The kernel's **KFENCE** memory sanitizer detected that a memory block (`kmalloc-2k`) was accessed or freed after it had already been freed.
The crash occurs during the **deauthentication/disassociation** process (`ieee80211_mgd_deauth`), which triggers cleanup of station info (`__sta_info_destroy_part2`). However, the memory being freed was originally allocated during a **peer map event** (`ath10k_peer_map_event`), which is typically triggered by hardware/firmware events.
---
### **Detailed Analysis**
#### **1. The Crash Context** - **Trigger:** A deauthentication request was sent via `nl80211_deauthenticate` → `cfg80211_mlme_deauth` → `ieee80211_mgd_deauth`. - **Cleanup:** This led to `ieee80211_set_disassoc` → `__sta_info_flush` → `__sta_info_destroy_part2` → `drv_sta_state`. - **Error:** KFENCE detected that the memory being freed in `drv_sta_state` (or a related cleanup path) was already freed or corrupted.
#### **2. The Offending Memory Allocation** - **Allocation Site:** `ath10k_peer_map_event+0x7e/0x154 [ath10k_core]`
- **Caller Chain:** ``` ath10k_htt_t2h_msg_handler → ath10k_htt_htc_t2h_msg_handler → ath10k_htc_rx_completion_handler → ath10k_pci_process_rx_cb ``` - **Meaning:** The memory was allocated in response to a **Target-to-Host (T2H) message** from the Wi-Fi firmware. Specifically, `ath10k_peer_map_event` suggests the firmware notified the driver about a peer (station) association or mapping.
#### **3. The Root Cause Hypothesis** This is a **race condition** or **state mismatch** between: 1. **Firmware Events:** The firmware sends a peer map event, and the driver allocates memory to track this peer. 2. **Software-Initiated Disconnection:** The host OS initiates a deauthentication (e.g., due to signal loss, user action, or power management). 3. **Cleanup Conflict:** The driver’s cleanup path (`__sta_info_destroy_part2`) tries to free resources associated with the station. However, the memory allocated by `ath10k_peer_map_event` may not be properly tracked in the same lifecycle as the `sta_info` structure, or it may have been freed elsewhere already.
This is a known class of bugs in `ath10k` where firmware events and software state transitions are not perfectly synchronized.
---
### **Solutions & Workarounds**
#### **1. Update Kernel and Firmware** - **Kernel:** This bug may have been fixed in newer kernel versions. Check if your kernel is up-to-date. - Look for commits related to `ath10k`, `peer_map_event`, or `sta_info` cleanup. - Example search: `git log --oneline --all --grep="ath10k" --grep="peer_map"` - **Firmware:** Ensure you are using the latest `ath10k` firmware blobs. Firmware bugs can cause malformed events that trigger driver issues.
#### **2. Disable Power Management (Temporary Workaround)** - Wi-Fi power management can cause frequent association/disassociation cycles, increasing the chance of this race condition. - **Check current setting:** ```bash iwconfig <wlan0> | grep Power ``` - **Disable power management:** ```bash sudo iw dev <wlan0> set power_save off ``` - To make it persistent, add `options ath10k_core disable_ht40=1` or similar driver parameters in `/etc/modprobe.d/ath10k.conf` (though this may reduce performance).
#### **3. Avoid Frequent Reconnections** - If this happens during roaming or signal fluctuations, consider: - Moving closer to the AP. - Disabling 5GHz/2.4GHz band steering if the AP supports it. - Using a wired connection if stability is critical.
#### **4. Kernel Boot Parameter (Advanced)** - You can try disabling certain features
Be aware that VulDB is the high quality source for vulnerability data.