A subtle race in the Linux kernel’s Bluetooth L2CAP code that could let the kernel touch freed memory has been fixed upstream: CVE-2024-36013 patches a slab use‑after‑free in l2cap_connect() by widening a critical section and removing a now‑dangerous return value, and distributions have started shipping the fix or backports. (nvd.nist.gov
Bluetooth’s Logical Link Control and Adaptation Protocol (L2CAP) is the kernel subsystem that glues higher‑level Bluetooth protocols to HCI transport drivers and to user‑space sockets. It allocates and manages per‑connection “channel” structures that represent L2CAP channels between peers; those channel objects are created and destroyed on asynchronous code paths driven by HCI events, workqueues, and administrative teardown paths. Because those lifetimes cross workqueues and locked regions, L2CAP code must be careful to hold the right locks and reference counts while object pointers are accessed. (osv.dev
CVE‑2024‑36013 is a classic race‑condition‑driven use‑after‑free that was detected by KASAN and by fuzzers such as Syzbot. The bug appears when a newly created channel is added to a connection list while under a connection lock, the lock is released, and another path (the connection‑delete path) removes and frees that channel while a third path still reads a field from the channel. The result is a read from freed memory — a slab UAF — observable in kernel KASAN traces and exploitable in theory for denial of service, information disclosure, or worse depending on the attack surface and constraints. (nvd.nist.gov
That design choice has operational consequences: changing a public or semi‑public function signature can make some backports fail to compile or require additional source changes, which in turn affects how quickly different distributions can ship fixes into older kernel branches. Several vendors therefore shipped both upstream stable commits and distribution‑specific backports. (suse.com
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
Bluetooth’s Logical Link Control and Adaptation Protocol (L2CAP) is the kernel subsystem that glues higher‑level Bluetooth protocols to HCI transport drivers and to user‑space sockets. It allocates and manages per‑connection “channel” structures that represent L2CAP channels between peers; those channel objects are created and destroyed on asynchronous code paths driven by HCI events, workqueues, and administrative teardown paths. Because those lifetimes cross workqueues and locked regions, L2CAP code must be careful to hold the right locks and reference counts while object pointers are accessed. (osv.devCVE‑2024‑36013 is a classic race‑condition‑driven use‑after‑free that was detected by KASAN and by fuzzers such as Syzbot. The bug appears when a newly created channel is added to a connection list while under a connection lock, the lock is released, and another path (the connection‑delete path) removes and frees that channel while a third path still reads a field from the channel. The result is a read from freed memory — a slab UAF — observable in kernel KASAN traces and exploitable in theory for denial of service, information disclosure, or worse depending on the attack surface and constraints. (nvd.nist.gov
What happened technically
The vulnerable sequence, in plain language
At a high level the faulty sequence is:- A thread in the L2CAP signaling path calls l2cap_connect(), which allocates a channel object (chan), inserts it into a connection list, and releases the connection lock.
- After unlocking, the signaling path proceeds to access fields in the channel (for example, chan->conf_state).
- Concurrently, another thread executing the connection‑teardown path (l2cap_conn_del) grabs the same connection lock, iterates the connection’s channel list, drops references, destroys channel objects and frees their memory — all while the original path has temporarily released the lock.
- If the timing is right (the classic race), the second thread frees chan while the first thread subsequently dereferences chan; KASAN reports a slab‑use‑after‑free. (nvd.nist.gov
The upstream fix
Kernel maintainers fixed the problem by extending the critical section so the channel cannot be freed from under the code that will use it. Concretely, the patch holds an extra reference and/or keeps the relevant lock held until the code that used chan finishes, and the l2cap_connect() function was changed to return void rather than a pointer — explicitly preventing caller code from relying on a returned pointer that might already be freed on some versions. The change is intentionally defensive: by making the function return void, future backports cannot accidentally continue to use a returned (potentially dangling) pointer. (lkml.orgThat design choice has operational consequences: changing a public or semi‑public function signature can make some backports fail to compile or require additional source changes, which in turn affects how quickly different distributions can ship fixes into older kernel branches. Several vendors therefore shipped both upstream stable commits and distribution‑specific backports. (suse.com
Why this matters: impact and exploitability
What the vulnerability enables
A use‑after‑free in kernel code gives an attacker several theoretical options:- Cause a kernel crash or a denial‑of‑service by forcing the kernel to dereference invalid memory.
- Leak kernel memory contents in some circumstances, if the freed memory is reallocated and the attacker can provoke a read of the stale pointer.
- In some very constrained scenarios, convert the memory corruption into arbitrary kernel code execution (a full compromise), but that requires specific heap layout manipulation and privilege/adjacency conditions that are non‑trivial. Advisories treat that path as theoretical rather than demonstrated. (nvd.nist.gov
Realistic attacker model
- Attack vector: adjacent (Bluetooth radio). An attacker generally needs to be in range or control the opposite endpoint. (nvd.nist.gov
- Privileges required: typically none on the victim host beyond having the Bluetooth stack active, though the attacker controls what the peer does across the link. (osv.dev
- Complexity: medium to high — an exploit requires precise timing and, for code execution, the ability to reliably manipulate kernel heap allocations. For denial‑of‑service, the requirements are far lower. (wiz.io
Where the fix landed and vendor responses
Major upstream and downstream trackers recorded the vulnerability and the patches.- The NVD and OSV entries document the issue, the KASAN call stacks, and the upstream mitigation approach (critical‑section extension and function return‑type change). (nvd.nist.gov
- The kernel patch and patch notes were discussed on LKML and included in stable tree commits; maintainers described holding the channel and locking to prevent early freeing. (lkml.org
- Several distributions published advisories and kernel errata that include fixes or backports: Ubuntu’s security tracker lists CVE‑2024‑36013 and related USN notices for specific Ubuntu releases, SUSE tracked the CVE and published fixes, and Red Hat opened a bug and associated errata recommending kernel upgrades; Red Hat’s internal tracking shows plans for fixed kernels in supported releases. (ubuntu.com
Detection, mitigation, and remediation guidance
Immediate mitigations (short of a kernel update)
If you cannot immediately install a vendor kernel update, consider the following mitigation steps in order of practicality:- Disable Bluetooth on servers and non‑essential endpoints where proximity attack surface is unacceptable. Disabling the kernel module or the Bluetooth service removes the attack vector entirely. This is the most reliable short‑term mitigation for high‑risk systems.
- Restrict physical and radio access: treat devices with active Bluetooth as needing physical security controls. Keep devices out of public spaces when possible and apply RF‑blocking measures for sensitive environments.
- Use host‑level intrusion detection to watch for kernel oopses or unexpected Bluetooth subsystem crashes: repeated KASAN/KMSG traces or frequent hci_rx_work/workqueue crashes may indicate attempted exploitation or instability. (nvd.nist.gov
How to verify whether you’re affected
- Check the installed kernel version: run uname -r and record the kernel release string. If your distribution has published an advisory that includes a fixed kernel package, compare the local kernel release to the vendor’s fixed‑in release. (ubuntu.com
- Consult your vendor’s security notices (Ubuntu USNs, Red Hat RHSA, SUSE security notices) for the CVE and the fixed package names or errata numbers; vendors often list affected kernels and package filenames. (ubuntu.com
- For development and test fleets, reproduce the KASAN report pattern in a safe environment using kernel builds with KASAN enabled; the KASAN stack traces in public advisories show the canonical signatures to match. Do not attempt fuzzing or exploit attempts on production systems. (nvd.nist.gov
Patching and update steps (recommended)
- Identify the vendor and exact distribution (Ubuntu, Debian, RHEL, SUSE, etc).
- Pull the vendor’s kernel security advisory for CVE‑2024‑36013 and note the fixed package(s) and required reboot policy.
- Schedule maintenance windows as required, test the kernel update in a staging environment, and roll to production following your change control process.
- Reboot systems after kernel updates. Kernel patches cannot be applied without a reboot unless you have a live patching solution that explicitly includes the fix. (ubuntu.com
Detection and hunting tips for security teams
- Hunt for kernel oops patterns referencing l2cap_connect, l2cap_connect.constprop, l2cap_send_cmd, l2cap_core.c and KASAN reports in /var/log/kern.log, dmesg, or your centralized log collector. The advisory KASAN traces show typical function names and offsets. (nvd.nist.gov
- Monitor for increased Bluetooth service crashes, frequent restart of bluetoothd (user‑space service), or repeated kernel messages containing "BUG: KASAN: slab‑use‑after‑free". Those signals are noisy but meaningful when correlated with Bluetooth events. (osv.dev
- On endpoints, check for unexplained application errors around Bluetooth communication (pairing, service discovery) at the same time as kernel logs. Correlate with known patched/unpatched host inventory. (suse.com
Risks, tradeoffs, and the long view
Strengths of the upstream fix
- The upstream patch is surgical and defensive: it prevents the race by extending the critical section and by removing an unsafe return value. That reduces the chance that callers (or future backports) will inadvertently reintroduce the UAF pattern. (lkml.org
- Multiple vendors tracked and distributed patches rapidly once the root cause and patch were public, and the KASAN evidence made the problem reproducible for maintainers. That evidence speeds both triage and testing. (nvd.nist.gov
Practical risks and backport complexity
- The change of function signature to void is a defensive hardening move, but it creates friction for backporting the patch into older stable kernels. Distributions that support older kernels may need to make companion source changes or accept the compile‑time signal that the older callers still expect a return value. That means some users on long‑lived kernels may see delays in arriving fixes. Administrators should prioritize vendor kernels that explicitly list the CVE as fixed rather than attempting to apply source patches blindly. (osv.dev
- The theoretical path to arbitrary kernel code execution remains difficult but non‑zero. Memory‑safety bugs in the kernel deserve high operational priority even when remote exploitation looks hard because stable, reproducible primitives sometimes become feasible with additional bugs or with more capable, targeted attackers. (wiz.io
Practical checklist for system owners
- 1.) Inventory: Identify hosts with Bluetooth enabled and kernel versions in use (uname -r); prioritize servers with exposed or user‑accessible Bluetooth radios. (ubuntu.com
- 2.) Patch: Apply vendor kernel updates that list CVE‑2024‑36013 as fixed; reboot in your normal maintenance window.
- 3.) Mitigate: Disable Bluetooth on machines where it is not needed. For devices that must have Bluetooth, restrict physical access and pairing policies. (suse.com
- 4.) Detect: Add a log hunt for KASAN slab‑UAF traces that reference l2cap_* symbols and respond to anomalous kernel oopses promptly. (nvd.nist.gov
- 5.) Vendor engagement: For embedded devices and appliances, contact the vendor for firmware that includes the kernel fix; do not assume automatic coverage. (cvefeed.io
What we could not independently verify
Several public trackers and advisories include KASAN traces and commit identifiers; however, direct inspection of some upstream commit pages on certain mirrors (for example, some stable git views) may be blocked by access restrictions at the time of writing. The core technical narrative — a race that frees chan while it is still used and an upstream fix that widens the critical section and changes l2cap_connect() to return void — is corroborated by multiple independent sources (NVD, LKML, vendor advisories). Administrators should still consult their vendor’s specific advisory for distribution‑specific package names and fixed kernel release numbers before planning updates. (nvd.nist.govConclusion
CVE‑2024‑36013 is a representative example of a kernel memory‑safety bug that emerges where asynchronous device events, workqueues, and short critical sections meet. The upstream maintainers fixed the defect with a clear defensive change — holding channels while they are used and removing a risky return value — and major distributions have followed with updates and errata. For system owners, the action is straightforward: inventory affected machines, apply vendor kernel updates as soon as they are available, and, when updates are not immediately possible, reduce the attack surface by disabling Bluetooth or imposing stricter physical/radio controls. While the bug’s highest‑risk outcomes (arbitrary kernel execution) remain theoretical and complex to achieve, the practical stability and availability risks (kernel crashes and service loss) justify prompt remediation. (nvd.nist.govSource: MSRC Security Update Guide - Microsoft Security Response Center
