CVE-2026-31499

What it actually does

This is a Linux kernel Bluetooth L2CAP race-condition/deadlock flaw in connection teardown. The vulnerable path calls delayed-work cancellation routines while holding the L2CAP connection lock, while the delayed work handlers can also try to acquire the same lock. If the timing aligns, the kernel can enter an AB-BA deadlock, leaving Bluetooth/L2CAP processing stuck and potentially causing a broader system hang or denial of service. The impact is availability only: there is no indicated confidentiality or integrity impact, and exploitation requires local low-privileged access according to the supplied CVSS vector.

Why it matters to the business

An attacker with local access to a system where the Bluetooth stack is enabled may be able to freeze Bluetooth processing or destabilize the host, causing service interruption and potentially requiring a reboot. This is most relevant for Linux desktops, laptops, kiosks, edge devices, embedded systems, and servers that ship with Bluetooth enabled. The current EPSS is very low and flat, it is not listed in CISA KEV, and no exploit maturity is reported, so broad active exploitation is not currently indicated; however, availability-sensitive systems should still prioritize kernel updates because successful exploitation can cause operational downtime.

How an attack unfolds

An attacker first needs local code execution as an unprivileged user on a Linux system with the affected Bluetooth/L2CAP kernel code reachable, typically where Bluetooth support is enabled and user space can interact with Bluetooth sockets or trigger Bluetooth connection lifecycle events. The attacker then repeatedly creates, manipulates, and tears down L2CAP-related Bluetooth activity to increase the chance that delayed work for L2CAP information or address updates is already running while connection deletion occurs. In the vulnerable implementation, connection deletion holds the connection lock while synchronously cancelling delayed work, and the delayed work functions may attempt to acquire that same lock. With the right timing, the two paths wait on each other and the kernel deadlocks. The attacker’s goal is denial of service: stuck kernel work, blocked tasks, soft lockups, impaired Bluetooth functionality, or a host requiring reboot. No public exploit or known threat actor activity is indicated by the supplied data.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the L2CAP connection deletion deadlock. The fix moves delayed-work cancellation before acquiring the L2CAP connection lock and uses disable_delayed_work_sync() to prevent the work from being rearmed after cancellation. Because no exact fixed package versions were supplied, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or embedded-device vendor once available. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, blacklisting or unloading Bluetooth kernel modules where operationally safe, blocking untrusted local shell access, limiting who can use Bluetooth-related interfaces, and applying standard local privilege controls. Mitigations should be treated as temporary because the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel package includes the vendor backport or upstream commit that changes l2cap_conn_del() to cancel/disable delayed work before taking conn->lock. Validate both the installed kernel package and the currently booted kernel, since Linux systems often require a reboot to run the newly installed kernel. Check whether Bluetooth is enabled and whether Bluetooth modules are loaded on systems that cannot be patched immediately. After remediation, run regression testing for Bluetooth pairing, L2CAP-dependent peripherals, and suspend/resume workflows. Review kernel logs after testing for absence of hung task, soft lockup, or Bluetooth L2CAP teardown warnings. For exposure validation, identify Linux hosts with affected kernel builds and enabled Bluetooth support, prioritizing endpoints and embedded systems where local users can execute code.

Typical attack path

1. Obtain local low-privileged access to a Linux system running an affected kernel with Bluetooth support enabled.
2. Confirm Bluetooth/L2CAP functionality is present and reachable from local user space.
3. Generate repeated Bluetooth L2CAP connection setup, update, timer, and teardown activity.
4. Race L2CAP connection deletion against delayed work handlers such as information timeout or identity address update processing.
5. Trigger the lock-ordering deadlock in the kernel Bluetooth stack.
6. Cause Bluetooth subsystem lockup, kernel task stalls, soft lockups, or system-wide denial of service requiring administrative recovery or reboot.

How to detect it

There are no unique, reliable indicators that prove exploitation from the supplied data; detection should focus on symptoms of attempted or successful denial of service in kernel and system logs. Review kernel logs, system journal, crash dumps, watchdog events, and endpoint telemetry for Bluetooth/L2CAP activity immediately preceding hung tasks, soft lockups, workqueue stalls, or unexplained reboots. Useful log sources include journalctl/kern.log, dmesg, /var/log/messages, /var/log/syslog, pstore/ramoops records, kdump/vmcore analysis, endpoint process telemetry, and audit logs showing local users repeatedly interacting with Bluetooth tooling or custom programs. Look for repeated Bluetooth connection setup/teardown activity followed by kernel messages mentioning L2CAP, delayed work, hung tasks, blocked tasks, soft lockups, or hard lockups. Correlate events with local user sessions, newly executed Bluetooth utilities, scripts, fuzzers, or suspicious binaries. Since the expected impact is availability-only, absence of file changes or network exfiltration does not rule out exploitation.

• Bluetooth: L2CAP
• l2cap_conn_del
• l2cap_info_timeout
• l2cap_conn_update_id_addr
• cancel_delayed_work_sync
• disable_delayed_work_sync
• watchdog: BUG: soft lockup
• BUG: soft lockup
• watchdog: Watchdog detected hard LOCKUP
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• rcu: INFO: rcu_preempt detected stalls
• workqueue:
• kernel: Bluetooth:
• bluetoothd
• btmon
• l2ping
• l2test
• hcitool

What your security team should do

• Inventory Linux systems with Bluetooth enabled or Bluetooth kernel modules loaded, prioritizing laptops, desktops, kiosks, edge devices, and embedded Linux appliances.
• Apply vendor-provided kernel updates that include the L2CAP deadlock fix, then reboot systems into the patched kernel.
• Where Bluetooth is not business-required, disable it through system configuration, kernel module policy, firmware/BIOS settings, or endpoint management controls.
• Restrict untrusted local access and monitor systems where unprivileged users can run code and interact with Bluetooth interfaces.
• Add monitoring for kernel soft lockups, hung tasks, and Bluetooth L2CAP-related errors to detect possible denial-of-service attempts or regression symptoms.
• Because EPSS is low, KEV status is false, and no exploit maturity is reported, prioritize remediation based on operational criticality and Bluetooth exposure rather than emergency internet-facing risk.
• For high-availability systems, schedule kernel patching with reboot coordination and rollback plans to avoid unplanned downtime.