CVE-2025-39860 Overview
CVE-2025-39860 is a use-after-free vulnerability [CWE-416] in the Linux kernel Bluetooth subsystem. The flaw resides in l2cap_sock_cleanup_listen() within net/bluetooth/l2cap_sock.c and was surfaced through a syzbot KASAN report. A race condition between concurrent socket close operations allows two threads to iterate the same accept queue, releasing a socket reference and then dereferencing the freed memory. Successful exploitation can corrupt kernel memory, crash the host, or enable local privilege escalation. The vulnerability affects multiple stable Linux kernel branches, including 6.17 release candidates, and downstream distributions such as Debian.
Critical Impact
A local attacker with the ability to open and close Bluetooth L2CAP sockets can trigger a use-after-free that may lead to kernel memory corruption and privilege escalation.
Affected Products
- Linux Kernel (multiple stable branches, including 6.17-rc1 through 6.17-rc4)
- Debian Linux 11.0
- Siemens products referenced in advisories ssa-032379 and ssa-089022
Discovery Timeline
- 2025-09-19 - CVE-2025-39860 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-39860
Vulnerability Analysis
The vulnerability is a use-after-free in the Bluetooth L2CAP socket cleanup path. When a listening L2CAP socket is closed, l2cap_sock_release() calls l2cap_sock_cleanup_listen(), which iterates pending child sockets via bt_accept_dequeue(). The cited commit introduced a call path where bt_accept_dequeue() executes without holding lock_sock() on the parent, breaking an implicit invariant that other call sites relied upon.
Two threads can therefore observe the same child socket during list iteration. Both call sock_hold() and lock_sock(), but only one holds the reference contributed by bt_accept_enqueue(). When the second thread progresses past bt_accept_unlink(), it drops the final reference and frees the socket. A subsequent access to sk->sk_lock by the first thread triggers a slab use-after-free detected by KASAN in debug_spin_lock_before() and do_raw_spin_lock().
Root Cause
The root cause is missing serialization around bt_accept_dequeue() in the release path. Every other caller invokes the routine under lock_sock(), but l2cap_sock_release() did not, permitting concurrent dequeue and unlink operations to race against the socket lifetime tracked by reference counts.
Attack Vector
Exploitation requires local access and the ability to create and close Bluetooth L2CAP sockets. An attacker races concurrent close() operations on a listening socket with pending accept-queue children to trigger the free-then-use sequence. Because the flaw is timing dependent, reliable exploitation typically requires kernel primitives to widen the race window. See the upstream fix commits listed in the vendor references for the corrected locking sequence.
// No verified proof-of-concept code is publicly available.
// The fix moves the l2cap_sock_cleanup_listen() call inside
// lock_sock(sk) within l2cap_sock_release() to serialize
// bt_accept_dequeue() against concurrent close() paths.
Detection Methods for CVE-2025-39860
Indicators of Compromise
- KASAN reports referencing slab-use-after-free in debug_spin_lock_before or do_raw_spin_lock with call stacks passing through bt_accept_dequeue, l2cap_sock_cleanup_listen, and l2cap_sock_release.
- Unexplained kernel oopses or panics on hosts with Bluetooth enabled and userspace processes closing L2CAP sockets.
- Presence of running kernels matching vulnerable versions listed in the affected CPE ranges without the referenced stable commits applied.
Detection Strategies
- Inventory kernel package versions across Linux endpoints and cross-reference against the fixed commits published on git.kernel.org/stable.
- Monitor dmesg and journald for KASAN, BUG, or general protection fault traces originating in net/bluetooth/l2cap_sock.c.
- Alert on abnormal process behavior that repeatedly opens and closes Bluetooth sockets, which can indicate race-window probing.
Monitoring Recommendations
- Forward kernel logs to a central analytics platform and create rules for Bluetooth subsystem crashes and KASAN reports.
- Track loading and use of the bluetooth and l2cap kernel modules on servers and workstations where Bluetooth is not required.
- Correlate local privilege escalation indicators with Bluetooth socket activity from non-privileged users.
How to Mitigate CVE-2025-39860
Immediate Actions Required
- Apply the upstream Linux kernel patches referenced in the vendor advisories, including commits 2ca99fc3512a, 306b09914130, 3dff390f55cc, 47f6090bcf75, 6077d16b5c0f, 83e1d9892ef5, 862c62810856, and 964cbb198f9c.
- Deploy distribution updates as they become available, including the Debian LTS advisories issued in October 2025.
- Review the Siemens security advisories ssa-032379 and ssa-089022 for affected industrial products and follow the vendor's remediation guidance.
Patch Information
The fix moves the l2cap_sock_cleanup_listen() invocation inside lock_sock(sk) within l2cap_sock_release(), restoring the locking invariant expected by bt_accept_dequeue(). Patches are available from the Linux stable tree, the Debian LTS announcement, and the Siemens ProductCERT advisory.
Workarounds
- Disable the Bluetooth stack on systems that do not require it by unloading and blacklisting the bluetooth and bnep kernel modules.
- Restrict CAP_NET_RAW and Bluetooth device access to trusted users to reduce the local attack surface.
- Stop and mask the bluetooth.service systemd unit on servers where Bluetooth functionality is not needed.
# Disable Bluetooth kernel modules and service
sudo systemctl stop bluetooth.service
sudo systemctl mask bluetooth.service
echo 'blacklist bluetooth' | sudo tee /etc/modprobe.d/blacklist-bluetooth.conf
echo 'blacklist btusb' | sudo tee -a /etc/modprobe.d/blacklist-bluetooth.conf
sudo modprobe -r btusb bluetooth 2>/dev/null || true
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

