CVE-2025-37795 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()
The ieee80211 skb control block key (set when skb was queued) could have been removed before ieee80211_tx_dequeue() call. ieee80211_tx_dequeue() already called ieee80211_tx_h_select_key() to get the current key, but the latter do not update the key in skb control block in case it is NULL. Because some drivers actually use this key in their TX callbacks (e.g. ath1{1,2}k_mac_op_tx()) this could lead to the use after free
below:
BUG: KASAN: slab-use-after-free in ath11k_mac_op_tx+0x590/0x61c Read of size 4 at addr ffffff803083c248 by task kworker/u16:4/1440
CPU: 3 UID: 0 PID: 1440 Comm: kworker/u16:4 Not tainted 6.13.0-ge128f627f404 #2 Hardware name: HW (DT) Workqueue: bat_events batadv_send_outstanding_bcast_packet Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x58/0x74 print_report+0x164/0x4c0 kasan_report+0xac/0xe8 __asan_report_load4_noabort+0x1c/0x24 ath11k_mac_op_tx+0x590/0x61c ieee80211_handle_wake_tx_queue+0x12c/0x1c8 ieee80211_queue_skb+0xdcc/0x1b4c ieee80211_tx+0x1ec/0x2bc ieee80211_xmit+0x224/0x324 __ieee80211_subif_start_xmit+0x85c/0xcf8 ieee80211_subif_start_xmit+0xc0/0xec4 dev_hard_start_xmit+0xf4/0x28c __dev_queue_xmit+0x6ac/0x318c batadv_send_skb_packet+0x38c/0x4b0 batadv_send_outstanding_bcast_packet+0x110/0x328 process_one_work+0x578/0xc10 worker_thread+0x4bc/0xc7c kthread+0x2f8/0x380 ret_from_fork+0x10/0x20
Allocated by task 1906: kasan_save_stack+0x28/0x4c kasan_save_track+0x1c/0x40 kasan_save_alloc_info+0x3c/0x4c __kasan_kmalloc+0xac/0xb0 __kmalloc_noprof+0x1b4/0x380 ieee80211_key_alloc+0x3c/0xb64 ieee80211_add_key+0x1b4/0x71c nl80211_new_key+0x2b4/0x5d8 genl_family_rcv_msg_doit+0x198/0x240
Freed by task 1494: kasan_save_stack+0x28/0x4c kasan_save_track+0x1c/0x40 kasan_save_free_info+0x48/0x94 __kasan_slab_free+0x48/0x60 kfree+0xc8/0x31c kfree_sensitive+0x70/0x80 ieee80211_key_free_common+0x10c/0x174 ieee80211_free_keys+0x188/0x46c ieee80211_stop_mesh+0x70/0x2cc ieee80211_leave_mesh+0x1c/0x60 cfg80211_leave_mesh+0xe0/0x280 cfg80211_leave+0x1e0/0x244
Reset SKB control block key before calling ieee80211_tx_h_select_key() to avoid that.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/09/2026
The vulnerability resides within the linux kernel's mac80211 subsystem, specifically in the ieee80211_tx_dequeue() function where a critical control block key handling flaw exists. This issue manifests when the skb (socket buffer) control block key that was established during initial queuing is removed prior to the ieee80211_tx_dequeue() call. The function subsequently invokes ieee80211_tx_h_select_key() to retrieve the current key, but this helper function fails to update the key within the skb control block when it encounters a NULL value. This design oversight creates a dangerous condition where drivers relying on these keys for transmission callbacks may access freed memory locations.
The operational impact of this vulnerability becomes evident through the kernel address sanitizer (KASAN) report which demonstrates a use-after-free error in the ath11k_mac_op_tx function. The stack trace reveals that a worker thread attempts to read a 4-byte value from address ffffff803083c248, which was previously freed by task 1494 during mesh network termination operations. The allocation history shows this memory was originally allocated during key creation through ieee80211_key_alloc() and subsequently freed when mesh networks were stopped via ieee80211_stop_mesh(). This particular scenario aligns with CWE-416, a use-after-free vulnerability where memory is accessed after it has been freed, making the system susceptible to potential privilege escalation or denial of service attacks.
The root cause stems from improper synchronization between key management and transmission queue processing. When drivers such as ath11k_mac_op_tx() attempt to access the control block key during transmission, they may encounter a stale or freed reference instead of a valid current key. This flaw represents a classic race condition in kernel networking code where state transitions are not properly synchronized. The fix requires resetting the SKB control block key before calling ieee80211_tx_h_select_key() to ensure that all subsequent operations work with consistent and valid key references, thereby preventing the use-after-free scenario entirely.
Security implications extend beyond simple memory corruption as this vulnerability could be exploited by malicious actors to gain elevated privileges within the kernel space or cause system instability through denial of service conditions. The ATT&CK framework categorizes this under privilege escalation techniques where kernel-level memory corruption can be leveraged for unauthorized access. Organizations should prioritize patching this vulnerability immediately, particularly in systems running mesh networking configurations or wireless infrastructure where the affected code paths are frequently exercised. Network administrators should monitor for potential system instability or unexpected behavior following patch deployment, as the fix may alter normal transmission flow characteristics in certain edge cases.