CVE-2022-50880 in Linux
要約
〜によって VulDB • 2026年05月09日
Based on the kernel log snippet provided, here is an analysis of the issue, its cause, and potential solutions.
### **Summary of the Issue** This is a **KASAN/KFENCE memory corruption bug** in the **`ath10k` Wi-Fi driver** (used for Qualcomm Atheros QCA988x, QCA99x0, etc.).
- **Error Type:** `kfence-#69` indicates a **use-after-free** or **out-of-bounds access** detected by the Kernel FENCE (KFENCE) allocator. - **Affected Component:** `ath10k_core` (the core driver for ath10k devices). - **Trigger:** The crash occurs during **deauthentication/disassociation** (`ieee80211_mgd_deauth`), specifically when cleaning up station info (`__sta_info_destroy_part2`). - **Root Cause Hint:** The KFENCE report shows a memory slab (`kmalloc-2k`) was allocated in `ath10k_peer_map_event` (during a peer map event from the firmware) but is being accessed after it was freed or is corrupted.
---
### **Detailed Analysis**
#### 1. **Call Stack Breakdown** - **Top of Stack (Crash Context):** - `drv_sta_state` → `__sta_info_destroy_part2` → `__sta_info_flush` → `ieee80211_set_disassoc` → `ieee80211_mgd_deauth` - This shows the system is tearing down a Wi-Fi connection (deauthenticating a station). - **Bottom of Stack (Allocation Context):** - `ath10k_peer_map_event` → `ath10k_htt_t2h_msg_handler` → `ath10k_htc_rx_completion_handler` - This shows the memory was allocated when the Wi-Fi firmware sent a "peer map" event (likely when a client associated or when the driver mapped a peer context).
#### 2. **What Went Wrong?** - The driver allocated memory for a peer context (`kmalloc-2k`) when the firmware reported a peer map event. - Later, during deauthentication, the driver tried to access or free this memory. - **KFENCE detected** that the memory was either: - **Already freed** (Use-After-Free), or - **Corrupted** (Out-of-Bounds write). - This is a **race condition** or **state management bug** in the `ath10k` driver where the peer context is not properly synchronized between firmware events and mac80211 station teardown.
---
### **Potential Causes** 1. **Driver Bug in `ath10k`:** - The driver may not be properly handling the case where the firmware sends a peer map event while the station is being torn down. - A known issue in older kernels where `ath10k` does not correctly handle peer context lifecycle during disassociation.
2. **Firmware Bug:** - The Wi-Fi firmware may be sending malformed or late peer map events after the driver has already started cleaning up.
3. **Kernel Version:** - This bug has been reported in various Linux kernel versions (e.g., 5.10–5.15). It may have been fixed in newer kernels.
---
### **Solutions & Workarounds**
#### **1. Update Kernel** - **Check if your kernel is up-to-date.** This bug has been fixed in several kernel versions. - If you are on **5.10 or older**, consider upgrading to **5.15+** or **6.x**. - Check the [Linux Kernel Git log](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/) for fixes related to `ath10k peer map` or `kfence`.
#### **2. Workaround: Disable Power Management** - Sometimes, power management states can trigger race conditions. Try disabling Wi-Fi power management: ```bash sudo iw dev wlan0 set power_save off ``` (Replace `wlan0` with your interface name.)
#### **3. Workaround: Reload Driver** - If the system becomes unstable, reload the `ath10k_pci` module: ```bash sudo modprobe -r ath10k_pci sudo modprobe ath10k_pci ```
#### **4. Update Firmware** - Ensure you have the latest firmware for your ath10k device: ```bash sudo apt install firmware-ath10k # Debian/Ubuntu sudo dnf install ath10k-firmware # Fedora
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.