CVE-2022-49910 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) -> __sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and freed by the second flow, therefore the callers of l2cap_reassemble_sdu can't use the SKB after that function returns. However, some places continue accessing struct l2cap_ctrl that resides in the SKB's CB for a short time after l2cap_reassemble_sdu returns, leading to a use-after-free condition (the stack trace is below, line numbers for kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429) ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493) ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth ret_from_fork (arch/x86/entry/entry_64.S:306) </TASK>
Allocated by task 43169: kasan_save_stack (mm/kasan/common.c:39) __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293) __alloc_skb (net/core/skbuff.c:414) l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth process_one_work (kernel/workqueue.c:2289) worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437) kthread (kernel/kthread.c:376) ret_from_fork (arch/x86/entry/entry_64.S:306)
Freed by task 27920: kasan_save_stack (mm/kasan/common.c:39) kasan_set_track (mm/kasan/common.c:45) kasan_set_free_info (mm/kasan/generic.c:372) ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328) slab_free_freelist_hook (mm/slub.c:1780) kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553) skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323) bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth sock_read_iter (net/socket.c:1087) new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401) vfs_read (fs/read_write.c:482) ksys_read (fs/read_write.c:620) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/11/2025
The vulnerability identified as CVE-2022-49910 represents a critical use-after-free condition within the Linux kernel's Bluetooth implementation, specifically affecting the L2CAP (Logical Link Control and Adaptation Protocol) layer. This flaw arises from a race condition between two parallel execution flows that handle Bluetooth socket data processing. The first flow processes incoming data through l2cap_reassemble_sdu which eventually calls chan->ops->recv and subsequently __sock_queue_rcv_skb to queue the socket buffer. The second flow executes bt_sock_recvmsg which can immediately dequeue and free the same socket buffer via skb_free_datagram. This race condition creates a window where code paths that continue to access data structures within the socket buffer's control block after l2cap_reassemble_sdu returns can encounter freed memory, resulting in a use-after-free scenario that can be exploited to cause system instability or potentially achieve privilege escalation. The vulnerability manifests through KASAN (Kernel Address Sanitizer) reports indicating memory access violations at specific locations within l2cap_rx_state_recv function, with stack traces showing the problematic access patterns and memory allocation/free sequences. The root cause lies in the improper handling of socket buffer references where the l2cap_ctrl structure, which resides in the socket buffer's control block, is accessed after the buffer may have been freed, violating fundamental memory safety principles. This type of vulnerability aligns with CWE-416 (Use After Free) and can be classified under ATT&CK technique T1068 (Exploitation for Privilege Escalation) when exploited in kernel contexts. The flaw particularly affects systems running kernel versions where the specific race condition exists, making it a significant concern for embedded systems and devices heavily reliant on Bluetooth connectivity. The fix implemented involves creating a local copy of the struct l2cap_ctrl data before the socket buffer can be freed, ensuring that all subsequent access operations occur on valid memory rather than potentially freed data, thereby eliminating the race condition and preventing the use-after-free scenario.
The technical impact of this vulnerability extends beyond simple memory corruption to potentially enable more sophisticated attacks. The race condition operates at a fundamental level within the kernel's network stack processing, where timing-sensitive operations between different execution contexts create opportunities for exploitation. The specific memory access pattern observed through KASAN indicates that the vulnerability occurs when the kernel attempts to read a single byte from a memory location that has already been freed, which is a classic symptom of use-after-free conditions. The allocation and freeing traces show that the socket buffer is allocated in one context and freed in another, with the freeing operation occurring immediately after the queuing operation, creating an extremely narrow window for the race condition to be exploited. This vulnerability demonstrates the complexity of concurrent programming in kernel space where multiple threads or workqueues can access shared data structures without proper synchronization mechanisms. The fact that this occurs within the Bluetooth subsystem means that any device running affected kernel versions could be vulnerable to attacks that leverage this condition, particularly in scenarios where Bluetooth data is being processed concurrently with socket read operations. The fix's approach of maintaining local copies of control data structures represents a defensive programming technique that prevents the race condition by ensuring that all required data is available in memory even after the original buffer has been processed and potentially freed.
Mitigation strategies for CVE-2022-49910 primarily involve updating to kernel versions that contain the specific patch addressing this race condition. System administrators should prioritize applying security updates to all affected systems, particularly those running embedded devices, IoT appliances, or any hardware that relies on Bluetooth connectivity. The patch implementation follows established security practices by eliminating the race condition through local data copying rather than introducing complex locking mechanisms that could introduce performance bottlenecks or additional race conditions. Organizations should also consider implementing monitoring solutions that can detect unusual memory access patterns or KASAN reports that may indicate exploitation attempts. The vulnerability highlights the importance of thorough testing in concurrent environments and proper synchronization mechanisms in kernel code. Security teams should perform vulnerability assessments to identify systems running potentially affected kernel versions and ensure that all Bluetooth-related services are properly patched. Network segmentation strategies may provide additional defense-in-depth measures, though the primary mitigation remains the kernel update. The fix's implementation demonstrates adherence to security best practices by addressing the root cause rather than merely masking symptoms, and it aligns with the principle of least privilege by ensuring that kernel memory operations remain safe even under concurrent access conditions. This vulnerability serves as a reminder of the critical importance of kernel security and the need for continuous security auditing of core system components.