Linux Kernel
CVE-2024-36013
HIGH
Severity by source
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Adjacent Bluetooth vector with no auth; AC:H because reliable race-condition exploitation requires precise timing between two concurrent kernel paths.
Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).
CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Lifecycle Timeline
7DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
Extend a critical section to prevent chan from early freeing. Also make the l2cap_connect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix.
Call stack summary:
[use] l2cap_bredr_sig_cmd l2cap_connect ┌ mutex_lock(&conn->chan_lock); │ chan = pchan->ops->new_connection(pchan); <- alloc chan │ __l2cap_chan_add(conn, chan); │ l2cap_chan_hold(chan); │ list_add(&chan->list, &conn->chan_l); ... (1) └ mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free
[free] l2cap_conn_del ┌ mutex_lock(&conn->chan_lock); │ foreach chan in conn->chan_l: ... (2) │ l2cap_chan_put(chan); │ l2cap_chan_destroy │ kfree(chan) ... (3) <- chan freed └ mutex_unlock(&conn->chan_lock);
============== BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0 net/bluetooth/l2cap_core.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311
AnalysisAI
Use-after-free in the Linux kernel's Bluetooth L2CAP subsystem allows an unauthenticated attacker within Bluetooth range to corrupt kernel memory by triggering a race condition in l2cap_connect(). The flaw arises because a channel object (chan) can be freed by a concurrent l2cap_conn_del() call while l2cap_connect() continues to access it outside the protecting mutex, leading to KASAN-confirmed slab-use-after-free. Impact includes potential kernel code execution or system crash; no public exploit identified at time of analysis and EPSS remains low at 0.46% (37th percentile), but the adjacent-network attack surface with no authentication requirement elevates practical concern on Bluetooth-enabled systems.
Technical ContextAI
The vulnerability resides in net/bluetooth/l2cap_core.c within the L2CAP (Logical Link Control and Adaptation Protocol) layer of the Linux kernel's Bluetooth stack. CWE-416 (Use After Free) describes the root cause: after l2cap_connect() releases conn->chan_lock, the newly allocated channel (chan) is added to conn->chan_l (step 1), but the lock is dropped before accessing chan->conf_state (step 4). Concurrently, l2cap_conn_del() can acquire the same lock, iterate conn->chan_l (step 2), decrement the reference count via l2cap_chan_put(), and free the channel via kfree() (step 3) - leaving l2cap_connect() with a dangling pointer. The fix extends the critical section (mutex-protected region) to cover the conf_state access. Affected CPEs include the broad Linux kernel lineage (cpe:2.3:o:linux:linux_kernel:*) through 6.9 rc1-rc7, indicating the bug is present across a wide span of kernel versions up to and including the 6.9 release candidates.
RemediationAI
Apply the upstream kernel patches available at https://git.kernel.org/stable/c/4d7b41c0e43995b0e992b9f8903109275744b658, https://git.kernel.org/stable/c/826af9d2f69567c646ff46d10393d47e30ad23c6, and https://git.kernel.org/stable/c/cfe560c7050bfb37b0d2491bbe7cd8b59e77fdc5. The exact patched release version is not independently confirmed from input data (upstream fix available via stable commits; released distribution-packaged version requires verification with your Linux vendor). For Debian, Ubuntu, RHEL, SUSE, or similar distributions, apply the latest kernel security update from your vendor's security advisory channel, which should incorporate these stable backports. As a compensating control where patching is not immediately possible, disabling Bluetooth entirely (via 'rfkill block bluetooth' or blacklisting the btusb and bluetooth kernel modules) eliminates the attack surface entirely - note this disables all Bluetooth functionality. Restricting L2CAP connections at the kernel level is not straightforwardly configurable without patching. Systems where Bluetooth is not operationally required should have it disabled regardless of patch status.
Same weakness CWE-416 – Use After Free
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today