CVE-2026-53358

What it actually does

This is a race-condition and lock-ordering flaw in the Linux kernel Bluetooth L2CAP implementation. During cleanup of listening L2CAP channels, the vulnerable code could close a channel while holding the socket lock and then attempt operations that require the L2CAP connection lock, violating the intended lock order. Under the right timing, this can create a deadlock or unsafe race during channel teardown. The most likely technical consequence is local or Bluetooth-adjacent denial of service through a hung kernel task, stalled Bluetooth stack, or system instability rather than direct code execution.

Why it matters to the business

Systems with Bluetooth enabled may be vulnerable to reliability issues if an attacker can interact with the Bluetooth stack or trigger repeated L2CAP connection setup and teardown. The practical business risk is service disruption, degraded endpoint availability, or device instability, especially for Linux-based laptops, embedded devices, kiosks, medical/industrial devices, and appliances that rely on Bluetooth. Current public risk indicators are low: EPSS is 0.00196, the vulnerability is not in CISA KEV, is not associated with ransomware campaigns, and no exploit maturity is reported; however, kernel flaws should still be remediated through normal patch cycles because they can affect broad product families once downstream distributions ship fixes.

How an attack unfolds

An attacker would need a path to exercise the vulnerable Bluetooth L2CAP code, typically by being within Bluetooth range or otherwise able to cause local Bluetooth L2CAP channel activity. The attacker repeatedly initiates and tears down L2CAP connections or triggers socket cleanup paths so that channel cleanup races with connection deletion. In the vulnerable path, cleanup runs while holding the parent socket lock and directly closes the L2CAP channel, causing lock acquisition in an unsafe order relative to the established connection-lock, channel-lock, socket-lock hierarchy. If the timing aligns, kernel threads handling Bluetooth work can deadlock or become stuck, potentially degrading or halting Bluetooth functionality and, in severe cases, affecting overall system responsiveness. There is no current evidence in the provided data of public exploit code, KEV exploitation, ransomware use, or named threat actor activity.

How to fix it

Apply the Linux kernel update that includes the Bluetooth L2CAP cleanup fix, where cleanup_listen() schedules l2cap_chan_timeout asynchronously instead of directly calling l2cap_chan_close() under the parent socket lock. Because no affected product list or exact fixed package versions were provided, use vendor advisories for the relevant Linux distribution, appliance, embedded platform, or kernel branch to identify the corrected kernel package. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, blocking or administratively disabling Bluetooth controllers on servers and fixed-purpose systems, limiting physical proximity to sensitive devices, and monitoring for Bluetooth-related kernel instability. Reboot after kernel updates where required so the fixed kernel is actually running.

How to confirm the fix worked

Confirm the running kernel version is at or above the fixed version supplied by the operating system or device vendor. Validate that the patched source or vendor changelog includes the L2CAP change that closes channels via the channel timer in cleanup_listen() rather than directly invoking l2cap_chan_close(). On Linux systems, verify the active kernel with uname -r and package-manager queries, then ensure the system has been rebooted into the updated kernel. For mitigation validation, confirm Bluetooth is disabled or blocked where intended using system Bluetooth service status, rfkill state, kernel module state, and device-management policy. If using kernel lockdep or debug builds, run controlled Bluetooth L2CAP connection and teardown tests and confirm no lock-order, hung-task, or Bluetooth L2CAP warnings are emitted.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and reachable over Bluetooth radio range, or obtain local ability to exercise Bluetooth sockets.
2. Initiate L2CAP connection activity against the target Bluetooth stack.
3. Trigger rapid or repeated L2CAP channel creation, listen cleanup, and teardown conditions.
4. Attempt to race L2CAP cleanup against connection deletion so the vulnerable lock-ordering path is reached.
5. Cause Bluetooth stack deadlock, hung kernel task, or system instability leading to denial of service.

How to detect it

Post-exploitation confirmation is difficult because this issue is primarily a kernel race leading to denial of service and may not leave a clean exploit artifact. Review kernel logs, system journals, crash dumps, and Bluetooth service logs for the period before any device freeze, reboot, Bluetooth outage, or hung-task event. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops, kdump/vmcore, systemd-coredump metadata, bluetoothd logs, audit logs for Bluetooth management commands, and EDR telemetry for local processes opening Bluetooth sockets. Look for repeated L2CAP connection setup/teardown immediately before kernel warnings, lockdep reports, hung tasks, soft lockups, or Bluetooth controller resets. If Bluetooth monitoring is available, review HCI/btmon captures for bursts of L2CAP signaling, repeated connection requests, disconnects, or abnormal activity from the same Bluetooth device address. Because no named threat actors or public exploit artifacts are provided, treat matching logs as suspicious reliability or exploitation indicators rather than definitive proof of compromise.

• possible circular locking dependency detected
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• BUG: soft lockup
• watchdog: BUG: soft lockup
• Bluetooth: L2CAP
• l2cap_chan_close
• cleanup_listen
• l2cap_chan_timeout
• l2cap_conn_del
• l2cap_chan_del
• l2cap_sock_teardown_cb
• l2cap_sock_close_cb
• bluetoothd
• btmon
• kernel: Bluetooth:
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• /sys/fs/pstore/
• /var/crash/

What your security team should do

• Inventory Linux systems, embedded devices, and appliances where Bluetooth is enabled or where the Linux Bluetooth stack is present.
• Prioritize patching devices with Bluetooth enabled in public, shared, mobile, industrial, healthcare, or physically accessible locations.
• Apply vendor kernel updates as part of the normal vulnerability remediation cycle; accelerate for high-availability devices where Bluetooth instability would cause operational disruption.
• Disable Bluetooth on servers, appliances, and endpoints that do not require it.
• Monitor kernel logs for Bluetooth L2CAP errors, hung tasks, lockdep warnings, soft lockups, and unexplained Bluetooth service failures.
• For managed endpoint fleets, verify that patched kernels are not only installed but actively running after reboot.
• Track downstream Linux distribution advisories because fixed versions may vary by kernel branch and vendor backport policy.