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

CVE-2025-21969 Overview

CVE-2025-21969 is a use-after-free vulnerability in the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) subsystem. The flaw occurs in the l2cap_send_cmd function where a race condition between the HCI sync command and HCI receive data work queue leads to accessing a freed l2cap_conn structure. When the HCI sync command releases the l2cap_conn object, the HCI receive data work queue may still reference this memory when sending data to the upper layer, resulting in a slab-use-after-free condition.

Critical Impact

A local attacker with low privileges can exploit this use-after-free vulnerability to potentially achieve arbitrary code execution with elevated privileges, cause system crashes, or corrupt kernel memory structures.

Affected Products

• Linux Kernel (multiple versions)
• Linux Kernel 6.14-rc1
• Linux Kernel 6.14-rc2

Discovery Timeline

• April 1, 2025 - CVE-2025-21969 published to NVD
• October 1, 2025 - Last updated in NVD database

Technical Details for CVE-2025-21969

Vulnerability Analysis

This use-after-free vulnerability stems from improper synchronization between two kernel work queues handling Bluetooth operations. The l2cap_conn structure is allocated when a Bluetooth L2CAP connection is established via l2cap_conn_add() and is freed during connection failure handling in hci_conn_failed().

The vulnerability manifests when the hci_rx_work work queue attempts to process incoming Bluetooth data and calls l2cap_send_cmd() to send L2CAP commands. If the hci_cmd_sync_work has already freed the l2cap_conn structure through the hci_abort_conn_sync() path, the receive work queue will access freed memory. This race condition is particularly dangerous because the KASAN (Kernel Address Sanitizer) report shows an 8-byte read from freed memory at address ffff8880271a4000, indicating the kernel is dereferencing a pointer to deallocated slab memory.

The fix involves adding proper HCI device locking (hci dev lock) to the HCI receive data work queue to ensure synchronization between the connection teardown and data reception paths.

Root Cause

The root cause is a missing synchronization primitive between concurrent kernel work queues. The hci_cmd_sync_work and hci_rx_work operate on shared l2cap_conn structures without adequate locking, creating a classic time-of-check-to-time-of-use (TOCTOU) race condition. When a connection abort occurs via hci_abort_conn_sync(), the l2cap_conn is freed through l2cap_connect_cfm(), but the receive path in hci_rx_work may still hold a stale pointer to this structure.

Attack Vector

The vulnerability requires local access and low privileges to exploit. An attacker with the ability to initiate Bluetooth operations could manipulate the timing of Bluetooth connection establishment and teardown to trigger the race condition. By carefully timing HCI commands and data reception, an attacker could cause the kernel to access freed memory, potentially leading to:

• Information disclosure through reading freed memory contents
• Denial of service through kernel panic or corruption
• Privilege escalation through controlled memory corruption

The attack vector involves manipulating Bluetooth HCI events to trigger the specific timing window where l2cap_conn is freed but still referenced. The vulnerability is triggered through the l2cap_recv_frame() -> l2cap_sig_channel() -> l2cap_sig_send_rej() -> l2cap_send_cmd() call chain, which ultimately calls l2cap_build_cmd() with a stale l2cap_conn pointer.

Detection Methods for CVE-2025-21969

Indicators of Compromise

• Kernel KASAN reports indicating slab-use-after-free in l2cap_send_cmd or l2cap_build_cmd functions
• Kernel panic or crash logs referencing net/bluetooth/l2cap_core.c with stack traces involving hci_rx_work
• Unexpected system instability when Bluetooth devices connect and disconnect rapidly
• Audit logs showing unusual Bluetooth HCI activity patterns

Detection Strategies

• Enable KASAN (Kernel Address Sanitizer) on systems to detect use-after-free conditions at runtime
• Monitor kernel logs for Bluetooth-related crashes or memory corruption warnings using dmesg filtering
• Deploy kernel debugging tools such as LOCKDEP to detect potential locking violations in Bluetooth subsystem
• Use SentinelOne's kernel-level monitoring to detect anomalous memory access patterns in the Bluetooth stack

Monitoring Recommendations

• Configure kernel logging to capture Bluetooth subsystem warnings at debug level (hci_core and l2cap_core modules)
• Implement real-time monitoring of kernel memory allocations and deallocations in the l2cap_conn slab cache
• Set up alerts for kernel OOPS or panic events originating from Bluetooth code paths
• Monitor for unusual patterns of Bluetooth connection establishment and termination

How to Mitigate CVE-2025-21969

Immediate Actions Required

• Apply the official kernel patches from the stable kernel tree immediately
• If patching is not immediately possible, consider disabling Bluetooth functionality on affected systems
• Review and update kernel configurations to enable memory safety features like KASAN for development and testing environments
• Restrict local user access to Bluetooth operations using appropriate permissions and policies

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix adds proper HCI device locking to the receive data work queue to synchronize access to l2cap_conn structures. The following commits contain the security fix:

• Commit 7790a79c6fce
• Commit b4f82f9ed43a
• Commit c96cce853542
• Commit f8094625a591

Update to a patched kernel version through your distribution's package manager or by compiling from source with the applied patches.

Workarounds

• Disable Bluetooth functionality at the kernel level by blacklisting the bluetooth module: add blacklist bluetooth to /etc/modprobe.d/blacklist.conf
• Restrict Bluetooth adapter access using udev rules to limit exposure to trusted processes only
• If Bluetooth is required, implement network segmentation and limit physical access to prevent local exploitation
• Use mandatory access control (SELinux/AppArmor) policies to restrict Bluetooth-related operations

# Disable Bluetooth module loading
echo "blacklist bluetooth" >> /etc/modprobe.d/bluetooth-blacklist.conf
echo "blacklist btusb" >> /etc/modprobe.d/bluetooth-blacklist.conf

# Remove loaded modules if present
modprobe -r btusb
modprobe -r bluetooth

# Verify modules are unloaded
lsmod | grep -i bluetooth