Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-21969

CVE-2025-21969: Linux Kernel Use-After-Free Vulnerability

CVE-2025-21969 is a use-after-free vulnerability in the Linux Kernel's Bluetooth L2CAP module that can lead to memory corruption. This article covers the technical details, affected versions, impact, and mitigation.

Updated:

CVE-2025-21969 Overview

CVE-2025-21969 is a use-after-free vulnerability [CWE-416] in the Linux kernel's Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) subsystem. The flaw resides in the l2cap_send_cmd function within net/bluetooth/l2cap_core.c. After the HCI synchronization command releases the l2cap_conn structure, the HCI receive data work queue continues to reference the freed object when forwarding data to upper layers. A local attacker with low privileges can trigger the race condition to read freed slab memory, potentially leading to kernel memory disclosure or arbitrary code execution at the kernel level.

Critical Impact

Local exploitation can produce kernel-level memory corruption, enabling privilege escalation or denial of service on systems with active Bluetooth interfaces.

Affected Products

  • Linux Kernel (multiple stable branches prior to the fix commits)
  • Linux Kernel 6.14-rc1
  • Linux Kernel 6.14-rc2

Discovery Timeline

  • 2025-04-01 - CVE-2025-21969 published to NVD
  • 2025-10-01 - Last updated in NVD database

Technical Details for CVE-2025-21969

Vulnerability Analysis

The vulnerability is a slab-use-after-free read detected by Kernel Address Sanitizer (KASAN) inside l2cap_send_cmd at net/bluetooth/l2cap_core.c:954. Two kernel work queues operate concurrently on the same l2cap_conn object: the HCI command synchronization worker and the HCI receive data worker. The synchronization path invokes hci_abort_conn_sync followed by hci_conn_failed, which calls l2cap_connect_cfm and frees the l2cap_conn structure via kfree. Simultaneously, the receive path executes hci_rx_work, eventually reaching l2cap_recv_frame and l2cap_sig_send_rej, which dereferences the already-freed connection pointer.

The upstream fix introduces an hci_dev_lock around the HCI receive data work queue. This serializes access between the synchronization and receive paths, preventing the receive worker from operating on a connection object that has been released.

Root Cause

The root cause is missing synchronization between the HCI command worker and the HCI receive data worker. Both reference the l2cap_conn object allocated in l2cap_conn_add, but no lock guarantees lifecycle consistency. When the command worker frees the structure through the hci_abort_conn_sync -> hci_conn_failed -> l2cap_connect_cfm chain, the receive worker still holds a stale pointer.

Attack Vector

Exploitation requires local access with the ability to interact with the Bluetooth stack. An attacker triggers concurrent Bluetooth connection abort and incoming L2CAP signaling frames to race the free and read operations. The KASAN report confirms the read of 8 bytes from freed slab memory inside l2cap_build_cmd. No code example is included because no verified public proof-of-concept exists for this issue.

// No verified exploitation code is publicly available for CVE-2025-21969.
// See the upstream KASAN report in the NVD description for the call traces
// of the freed-by and use-after-free paths.

Detection Methods for CVE-2025-21969

Indicators of Compromise

  • KASAN reports in dmesg referencing slab-use-after-free in l2cap_send_cmd or l2cap_build_cmd.
  • Unexpected kernel oops or panics involving hci_rx_work, l2cap_recv_frame, or l2cap_sig_send_rej call paths.
  • Bluetooth stack instability coinciding with rapid connection establishment and teardown sequences from nearby devices.

Detection Strategies

  • Enable KASAN on test kernels to surface slab-use-after-free conditions in the L2CAP code path during fuzzing or QA.
  • Monitor kernel logs for crashes in net/bluetooth/l2cap_core.c and correlate against Bluetooth pairing or disconnect events.
  • Inventory Linux systems running kernels prior to the patched commits using vulnerability management or configuration baseline tooling.

Monitoring Recommendations

  • Collect kernel ring buffer and journald logs centrally and alert on Bluetooth subsystem oops messages.
  • Track Bluetooth daemon (bluetoothd) restarts and abnormal HCI device resets on endpoints with active wireless interfaces.
  • Audit which workstations and embedded Linux devices have Bluetooth enabled but do not require it for operational use.

How to Mitigate CVE-2025-21969

Immediate Actions Required

  • Apply the upstream kernel patches referenced in the Linux stable git tree to all affected systems.
  • Disable the Bluetooth subsystem on servers, virtual machines, and endpoints that do not require it until patches are deployed.
  • Restrict local account access on multi-user systems to limit who can interact with Bluetooth interfaces.

Patch Information

The Linux kernel maintainers released the fix across multiple stable branches. Refer to the upstream commits: 7790a79c6fce, b4f82f9ed43a, c96cce853542, and f8094625a591. Update to the corresponding stable kernel release from your distribution.

Workarounds

  • Unload the Bluetooth kernel modules (btusb, bluetooth) on hosts that do not require wireless connectivity.
  • Blacklist Bluetooth modules in /etc/modprobe.d/ to prevent automatic loading at boot.
  • Stop and disable bluetooth.service via systemctl on systems where Bluetooth functionality is non-essential.
bash
# Disable and blacklist the Bluetooth stack until patches are applied
sudo systemctl stop bluetooth.service
sudo systemctl disable bluetooth.service
echo "blacklist bluetooth" | sudo tee /etc/modprobe.d/disable-bluetooth.conf
echo "blacklist btusb" | sudo tee -a /etc/modprobe.d/disable-bluetooth.conf
sudo modprobe -r btusb bluetooth

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.