CVE-2026-72336 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: 6lowpan: hold L2CAP conn across debugfs control
get_l2cap_conn() looks up an LE hci_conn under hdev protection, but then drops that protection before reading hcon->l2cap_data and before lowpan_control_write() later dereferences conn->hcon. A disconnect or device close can tear down the same L2CAP connection in that window.
The buggy scenario involves two paths, with each column showing the order within that path:
6LoWPAN control write: HCI disconnect/device close: 1. get_l2cap_conn() finds hcon 1. hci_disconn_cfm() dispatches and hcon->l2cap_data. the L2CAP disconnect callback. 2. get_l2cap_conn() drops hdev 2. l2cap_conn_del() clears protection and returns conn. hcon->l2cap_data and drops the L2CAP connection reference. 3. lowpan_control_write() reads 3. hci_conn_del() removes and drops conn->hcon. the HCI connection.
Take a reference to the L2CAP connection with l2cap_conn_hold_unless_zero() while hdev is still locked, and drop that reference after the debugfs command's last use of conn. This mirrors the existing L2CAP ACL receive-side handoff and keeps the connection dereferenceable after leaving hdev protection. Export the existing helper so the bluetooth_6lowpan module can use the same lifetime primitive.
Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in lowpan_control_write+0x374/0x520 The buggy address belongs to the object at ffff888111b9d000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes inside of freed 1024-byte region [ffff888111b9d000, ffff888111b9d400)
Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 lowpan_control_write+0x374/0x520 (net/bluetooth/6lowpan.c:1131) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __debugfs_file_get+0xf7/0x400 full_proxy_write+0x9e/0xd0 vfs_write+0x1b0/0x810 ksys_write+0xd2/0x170 dnotify_flush+0x32/0x220 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 __kasan_kmalloc+0xaa/0xb0 l2cap_conn_add+0x45/0x520 l2cap_chan_connect+0xac6/0xd90 l2cap_sock_connect+0x216/0x350 __sys_connect+0x101/0x130 __x64_sys_connect+0x40/0x50 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 hci_conn_hash_flush+0xc0/0x140 hci_dev_close_sync+0x41a/0xb00 hci_dev_close+0x12f/0x160 hci_sock_ioctl+0x157/0x570 sock_do_ioctl+0xf7/0x210 sock_ioctl+0x32f/0x490 __x64_sys_ioctl+0xc7/0x110 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f kasan_record_aux_stack+0xa7/0xc0 insert_work+0x32/0x100 __queue_work+0x262/0xa60 queue_work_on+0xad/0xb0 l2cap_connect_cfm+0x4ef/0x670 hci_le_remote_feat_complete_evt+0x247/0x430 hci_event_packet+0x360/0x6f0 hci_rx_work+0x2ae/0x7a0 process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's bluetooth 6lowpan implementation where a race condition allows for use-after-free conditions during Bluetooth low energy connection handling. The flaw occurs in the get_l2cap_conn() function which retrieves an LE hci_conn under hdev protection but subsequently releases that protection before completing all operations on the connection data. This creates a temporal window where another process can disconnect or close the device, causing the L2CAP connection to be torn down while the original thread still attempts to access it through lowpan_control_write(). The issue manifests as a slab-use-after-free error when the system tries to read conn->hcon after the connection has been freed. This vulnerability directly maps to CWE-416 Use After Free and falls under the ATT&CK technique T1059 Command and Scripting Interpreter, specifically targeting kernel-level execution paths. The race condition arises from improper reference counting where the L2CAP connection reference is not held consistently across the protection window.
The technical implementation flaw involves a missing reference hold during the debugfs control operation sequence. When get_l2cap_conn() finds the hcon and reads hcon->l2cap_data, it drops hdev protection before completing the debugfs write operation. This allows concurrent execution paths to proceed where one path disconnects the connection while another attempts to dereference it. The specific call trace shows the error occurring in lowpan_control_write at line 1131 where an 8-byte read is performed on a freed memory region, with the allocation and deallocation traces clearly showing the sequence of events leading to the use-after-free scenario. The kernel's KASAN (Kernel Address Sanitizer) detection confirms that the freed object belonged to the kmalloc-1k cache and was 1024 bytes in size.
The operational impact of this vulnerability extends beyond simple memory corruption, as it creates a potential vector for privilege escalation or system instability within Bluetooth subsystems. An attacker could potentially exploit this race condition to cause kernel panics or achieve arbitrary code execution through carefully timed device disconnection sequences. The vulnerability affects systems running Linux kernels with bluetooth 6lowpan support, particularly those handling LE connections through debugfs interfaces. The flaw demonstrates poor resource management practices in concurrent kernel programming where reference counting and protection mechanisms are not properly synchronized. This issue also aligns with ATT&CK technique T1499 Endpoint Denial of Service, as the race condition could lead to system crashes or denial of service conditions when attempting to manipulate bluetooth 6lowpan connections through debugfs interfaces.
The recommended mitigation involves implementing proper reference counting using l2cap_conn_hold_unless_zero() while maintaining hdev lock protection throughout the operation. This approach ensures that the L2CAP connection remains valid for the duration of the debugfs command execution, mirroring existing patterns used in L2CAP ACL receive-side handling. The fix requires exporting the existing helper function to allow the bluetooth_6lowpan module to utilize the same lifetime management primitive consistently. This solution addresses the root cause by ensuring that connection references are properly held across the protection window and released only after all operations complete, preventing the use-after-free condition from occurring. The implementation aligns with kernel security best practices for concurrent resource management and follows established patterns within the Linux kernel codebase for handling reference counting in multi-threaded environments.