Linux Bluetooth CVE-2025-21969: Kernel Use-After-Free in L2CAP Fixed Upstream

A newly disclosed Linux-kernel vulnerability in the Bluetooth L2CAP implementation — tracked as CVE-2025-21969 — is a slab use-after-free in l2cap_send_cmd that can trigger kernel memory corruption and sustained denial-of-service, and it has been fixed upstream by synchronizing the HCI receive path with an hci device lock; system administrators and device vendors should treat this as a high-priority patching item for kernels in the vulnerable series.

Background / Overview​

Bluetooth’s L2CAP (Logical Link Control and Adaptation Protocol) layer mediates higher-level protocols and application traffic over Bluetooth links. In late March and early April 2025 researchers and maintainers triaged a Kernel Address Sanitizer (KASAN) hit that shows the Bluetooth HCI receive workqueue referencing an l2cap connection object after it was freed — a classic use-after-free that results in a slab read of already-freed memory during execution of l2cap_send_cmd. The issue was assigned CVE-2025-21969 and given a CVSS v3.1 score of 7.8 (High) by public vulnerability databases.
The bug’s practical upshot is twofold. First, a local actor (or a proximate Bluetooth attacker interacting with a vulnerable Bluetooth adapter) can provoke kernel memory corruption — most commonly manifesting as a kernel crash (a reliable denial-of-service). Second, in some exploitability assessments the corruption could theoretically be escalated into privilege escalation or information disclosure depending on heap layout and attacker sophistication, although there is, to date, limited public evidence of a working remote code-execution exploit in the wild.

---

Technical deep dive: what the code does and why it fails​

L2CAP, HCI, and the race​

At a high level, Bluetooth packet flow in the kernel moves data from the HCI device layer up through core Bluetooth services, into L2CAP, and then to higher-level protocol handlers or sockets. The issue at the center of CVE-2025-21969 stems from a race between two kernel contexts:

• the HCI sync command path that releases (frees) an l2cap_conn structure when a connection aborts or is torn down; and
• the HCI receive workqueue (hci_rx_work) that processes incoming ACL data and may call into L2CAP to build and send L2CAP control commands (via l2cap_send_cmd).

When the sync path frees an l2cap_conn while the receive workqueue still has a reference, the workqueue can dereference pointers inside the now-freed structure. KASAN reported a read of 8 bytes at an invalid address during l2cap_send_cmd, which is consistent with a slab-use-after-free. The fix adds an explicit hci device lock in the receive workqueue path so that object lifetime and access are synchronized.

Why this is a slab use-after-free, not a null-pointer bug​

KASAN reports and the kernel call traces include detailed allocator and stack traces showing allocation and free events for the underlying objects. The diagnostic stack shows l2cap_send_cmd performing a read where the backing object had been freed by an earlier worker. This is not a missing NULL check; it’s unsynchronized concurrent access that allows a freed memory object to be read. In practice, unsynchronized access of freed objects leads to undefined behavior: crashes, corrupted control structures, or — in rare, targeted circumstances — controlled memory corruption that could be leveraged further.

Where the fix sits (upstream change)​

Upstream maintainers addressed the issue by adding the hci device lock to the receive-workqueue path so that the operations which previously raced cannot interleave in an unsafe way. The kernel stable branch(s) received commits backported where appropriate, and downstream distributors issued advisories and kernel package updates that incorporate the upstream patch. Multiple kernel stable releases and vendor advisories mention the addition of synchronization in the hci receive path as the corrective action.

---

Who’s affected — scope, kernel versions, and vendor posture​

Affected kernel ranges​

Public vulnerability trackers and vendor advisories identify the vulnerable code in multiple kernel series and note the patched thresholds. Distributions and trackers list the issue against kernels prior to the patched releases in the 6.6.x, 6.12.x and 6.13.x families; common guidance is that kernels earlier than the following are vulnerable:

• 6.6 series: prior to 6.6.84 (patched in the 6.6.x lineage)
• 6.12 series: prior to 6.12.20 (patched in 6.12.20)
• 6.13 series: prior to 6.13.8 (patched in 6.13.8)

These ranges have been reported consistently across multiple sources and vendor trackers. Check your distribution’s security advisory to find the exact patched package for your release.

Which products and deployments are at real risk​

• Standard desktop and server Linux distributions that use upstream kernel series in the listed ranges are at risk when Bluetooth is enabled and supported by the machine’s kernel. Vendor kernels that have backported fixes may or may not map to the same version numbers; always consult vendor advisories.
• Embedded devices and IoT appliances that run Linux kernels with older Bluetooth stacks are at elevated risk because firmware and OEM kernel images are often slow to receive security backports. Such devices frequently cannot be updated by end users, which creates a long tail of vulnerable systems.
• Cloud or virtual machines that expose host Bluetooth devices (rare but possible in specialized environments) may be affected when guest or host kernels are in vulnerable ranges; typical public cloud VMs are not commonly shipped with active Bluetooth stacks unless specifically enabled.

---

Real-world impact and attacker model​

Primary impact: availability (denial-of-service)​

The most immediate and reliable effect of CVE-2025-21969 is a kernel crash resulting in a full system or service restart — an absolute availability impact. Public vulnerability descriptions explicitly call out the potential for sustained or persistent loss of availability because a remote or local actor can repeatedly trigger the race that leads to a use-after-free and crash. For environments that depend on local Bluetooth services (for pairing, device connectivity, or telemetry), attackers can deny the Bluetooth service and potentially force system reboots. Microsoft’s advisory classification in the supplied summary likewise stresses total loss of availability as a primary outcome.

Secondary risks: information disclosure and escalation (theoretical, but plausible)​

A use-after-free can, in principle, be escalated beyond DoS if an attacker can achieve deterministic heap manipulation and control of freed memory contents. Some security assessments have flagged the potential for information disclosure or privilege escalation depending on exploit maturity and environment-specific memory layout. However, public telemetry and threat feeds show no widely confirmed exploited-in-the-wild campaigns or public proof-of-concept code as of the last community reporting; the EPSS and exploit-tracking services report low exploitation likelihood so far. Treat these higher-impact outcomes as plausible but currently speculative — they increase the severity requirement for patching but do not yet indicate active mass exploitation.

Attacker prerequisites​

• Local access to the host or proximity to the vulnerable Bluetooth radio is required; the vector is local/adjacent (CVSS vector AV:L).
• Privileges required are low in many assessments (PR:L), and no user interaction is necessary after the attack steps are performed in many exploit scenarios. This combination makes the flaw attractive for adversaries with local access to Bluetooth (e.g., in public spaces, or where an attacker can pair maliciously).

---

Detection: how to tell whether this has happened or can happen on your systems​

• Check kernel version and downstream vendor advisories. On a Linux system run uname -r and compare with vendor security advisory or the patched kernel versions listed above. If your distribution labels kernels differently, consult its security tracker.
• Inspect system logs and dmesg for KASAN or kernel oops traces that specifically mention l2cap_send_cmd or KASAN slab-use-after-free entries. Example diagnostic output lines observed in reports reference messages like: "KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954" — seeing similar oops or stack traces indicates that the race occurred on that machine.
• Monitor for increased crashes of Bluetooth-related services, random kernel panics tied to the Bluetooth workqueue, or repeated device reboots in environments where Bluetooth traffic is present. These operational signals are the most visible symptom of exploitation or accidental trigger.

---

Mitigation and remediation guidance (practical steps)​

Immediate mitigations (when you cannot patch immediately)​

• Disable Bluetooth at the OS or system level. For systems where Bluetooth is not required, disable the kernel modules or Bluetooth service to eliminate the attack surface. This is the simplest and most reliable temporary mitigation.
• Restrict physical or wireless access to the environment. In shared spaces, limiting Bluetooth-capable devices and preventing unknown devices from pairing reduces the chance an adversary can provoke the condition.
• For managed hosts, apply host-based hardening: run with minimal Bluetooth exposure, use network/host segmentation, and enforce policies that prevent local untrusted users from interacting with Bluetooth subsystems.
• Consider kernel hardening features where available (e.g., KASLR, hardened allocators) but recognize these are not a substitute for the fix; they can reduce exploitability but not eliminate the use-after-free behavior itself.

Patch and update (recommended)​

• Consult your distribution’s security advisory for the CVE and install the vendor-supplied kernel update that includes the upstream fix. Vendors that published advisories include multiple enterprise distributions; SUSE, Debian/Ubuntu trackers and others have listed patched kernel packages.
• For kernel series where upstream patched commits are available, update to the kernel versions that include the fix (for example, the patched thresholds listed in the affected versions section). If you operate custom or embedded kernels, pull the specific upstream commit into your tree and rebuild with the fix applied.
• Reboot systems after kernel updates to ensure the updated code is in use. Validate after reboot by re-checking uname -r and verifying Bluetooth functionality for expected devices.
• For fleet management, push updates via your standard configuration management pipelines and treat this CVE as a high-priority kernel fix.

Long-tail and embedded device strategies​

• For IoT and embedded devices with vendor-controlled kernels, contact the device maker for a firmware/kernel security update. If updates are not forthcoming, mitigate by disabling or physically removing Bluetooth hardware where feasible, or by applying network-level compensating controls that reduce attacker proximity. Embedded deployments typically require special attention because many are never updated after deployment.

---

Detection and logging playbook (for defenders)​

• Add alert rules for kernel oops patterns that include "KASAN", "slab-use-after-free", "l2cap_send_cmd", and "net/bluetooth/l2cap_core.c". Feed these into centralized SIEM to detect correlated or repeated incidents across your estate.
• Prioritize hosts with active Bluetooth use (point-of-sale, kiosks, engineering workstations) for early remediation and auditing.
• For hosts that cannot be updated immediately, increase monitoring frequency and isolate them from sensitive networks.
• Keep a record of kernel panics and correlate with local Bluetooth events or change windows to better understand whether the issue is benign or signal of an attack.

---

Risk analysis and critical perspective​

Strengths in the response​

• The kernel community reacted quickly with targeted fixes that add synchronization in the HCI receive path; the patch is narrowly scoped to the race condition and therefore suitable for backporting to stable kernels. Multiple vendor advisories and stable updates were issued, which means the fix is available to most mainstream distributions and enterprise platforms.
• The vulnerability was found via KASAN instrumentation, which demonstrates the continued value of dynamic sanitizers in uncovering low-level concurrency bugs before or shortly after upstream exposure. KASAN traces provide high-fidelity diagnostics useful for remediation and forensics.

Unresolved risks and the long tail​

• The primary risk is deployment latency. Embedded devices, vendor kernels, and long-lived appliances often lag in receiving these fixes. That creates a long tail of vulnerable devices that cannot be trivially updated by end users and therefore remain exploitable for extended periods. That gap is where attackers with physical proximity or local access derive the most value.
• While there is no clear public proof-of-concept exploit widely circulated, the vulnerability class (use-after-free in kernel Bluetooth code) has historically been valuable to sophisticated attackers who can manipulate memory layout. The absence of public exploitation now should not be taken as evidence that exploitation is impossible or not in development. Defenders must assume motivated attackers will attempt to weaponize such races.
• Vendor and downstream packaging complexity (backports, ABI-stable kernels, vendor-specific patches) means that simply quoting upstream kernel version numbers is insufficient; operators must verify the presence of the specific fix in their environment rather than assume a kernel-version naming map. This requirement increases the operational burden of secure patching.

---

Practical checklist for administrators (actionable, ranked)​

• Immediately determine whether Bluetooth is required on your host. If not, disable it system-wide and schedule a patch window.
• Check kernel version: run uname -r and cross-check with your vendor’s CVE advisory to determine if your package is patched.
• If running an unpatched kernel and Bluetooth is required, schedule or apply the vendor-supplied kernel update that includes the upstream fix and reboot.
• For embedded devices: contact the OEM about firmware updates; if no update is available, isolate or disable the Bluetooth interface.
• Add log-based detectors for KASAN or l2cap stack traces to your monitoring systems; treat any matches as high-priority incidents and perform forensic capture.

---

Final assessment and recommendations​

CVE-2025-21969 is a high-impact kernel race that reliably produces denial-of-service and has theoretical potential for privilege escalation in the right circumstances. The bug’s root cause — unsynchronized access to l2cap_conn from HCI receive work and sync/free paths — is typical of concurrency defects in complex kernel subsystems. The good news is that the upstream fix is straightforward and has been backported by distributors; the hard news is that many devices will remain vulnerable until vendors and OEMs deliver updates or until administrators proactively replace or mitigate affected hardware.
From a practitioner’s perspective, treat this CVE as a high-priority kernel patch: verify whether your kernel packages contain the upstream synchronization commit or install vendor updates, and apply compensating mitigations (disable Bluetooth, tighten physical/wireless proximity controls) where updates cannot be immediately deployed. Maintain vigilant logging for KASAN-style oopses or l2cap stack traces, and prioritize remediation for devices that are difficult to update or that operate in exposed locations.
The underlying engineering lesson is familiar but worth repeating: kernel subsystems that juggle asynchronous workqueues and object lifetimes must be carefully synchronized; the cost of a missed lock is opaque, low-frequency failure modes that are nevertheless exploitable and disruptive. Continued investment in sanitizer testing, coordinated disclosure, and rapid vendor patching remains the most practical route to shrinking the attack surface these defects expose.

---

Conclusion
CVE-2025-21969 is a timely reminder that even longstanding protocols like Bluetooth still host concurrency pitfalls that can ripple into severe availability and security issues. Operators should verify their exposure, prioritize kernel updates from their distribution or OEM, and apply immediate mitigations where updates are not yet available. The fix exists upstream and downstream — the remaining task is fast and comprehensive deployment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center