CVE-2026-53357

What it actually does

This is a Linux kernel Bluetooth L2CAP use-after-free race involving listening socket cleanup and concurrent HCI disconnect handling. A child socket and its associated L2CAP channel can be freed by the disconnect path while the listening-socket close path still references them, resulting in kernel memory use after free. The most likely impact is local kernel crash or instability; because the bug occurs in kernel memory management, privilege escalation or arbitrary kernel code execution may be theoretically possible depending on allocator state, kernel hardening, and exploitability, but no public exploitation is currently indicated.

Why it matters to the business

Systems with Bluetooth enabled may be exposed to local denial-of-service risk and potential kernel compromise if an attacker can trigger the race condition. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so widespread exploitation is not indicated; however, Linux kernel flaws should still be prioritized on laptops, workstations, kiosks, embedded Linux devices, and servers where Bluetooth is enabled or exposed to untrusted users.

How an attack unfolds

An attacker with local access, or code execution in an unprivileged context that can interact with Bluetooth sockets, attempts to create L2CAP listening sockets and repeatedly race socket accept/close behavior against Bluetooth HCI disconnect events. During the race, the kernel disconnect path may free a child socket and L2CAP channel while the listening socket cleanup path continues to operate on the same freed objects. Successful triggering can cause a kernel use-after-free, commonly resulting in a KASAN report, kernel oops, panic, or system instability. Turning this into reliable privilege escalation would require precise heap grooming and bypassing kernel mitigations such as KASLR, slab hardening, SMEP/SMAP, and other distribution-specific protections.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the Bluetooth L2CAP lifetime/reference handling issue. If vendor fixed package versions are not yet available, track distribution kernel advisories and update to the first kernel build that backports the fix. Reboot after installing the fixed kernel to ensure the patched kernel is running. As interim mitigation, disable Bluetooth where it is not required, block loading of Bluetooth kernel modules where operationally acceptable, and restrict local users or workloads from accessing Bluetooth functionality. On high-risk systems, consider disabling Bluetooth in firmware/BIOS/UEFI or through operating system policy until patched.

How to confirm the fix worked

Confirm the running kernel version is the vendor-fixed build, not merely that the package has been installed. Validate after reboot using kernel version and package inventory checks. Confirm whether Bluetooth is enabled, whether Bluetooth modules are loaded, and whether L2CAP support is available. For mitigation validation, verify Bluetooth services are stopped, adapters are disabled, and modules such as bluetooth, btusb, and related HCI/L2CAP components are not loaded where they are not needed. For patched kernels, review vendor changelogs or kernel source/backport notes for the Bluetooth L2CAP accept queue reference/lifetime fix associated with l2cap_sock_cleanup_listen, l2cap_conn_del, and bt_accept_dequeue behavior.

Typical attack path

1. Obtain local execution on a Linux system with Bluetooth support enabled and accessible.
2. Create or manipulate Bluetooth L2CAP listening sockets.
3. Trigger not-yet-accepted child socket handling through accept queue behavior.
4. Race listening socket close or cleanup against an HCI disconnect event processed through kernel Bluetooth workqueue handling.
5. Cause the disconnect path to free the child socket or L2CAP channel while cleanup code still references it.
6. Achieve kernel crash, denial of service, or attempt further exploitation through controlled use-after-free memory reuse.

How to detect it

Review host telemetry and kernel logs for evidence of prior triggering. Useful sources include journald, syslog, dmesg, kernel oops/panic records, crash dumps, KASAN reports, audit logs for unusual local process activity around Bluetooth sockets, and endpoint telemetry showing repeated Bluetooth socket creation or abnormal crashes. Look for use-after-free reports involving l2cap_sock_kill, l2cap_sock_cleanup_listen, l2cap_conn_del, hci_rx_work, or L2CAP/HCI disconnect handling. On production kernels without KASAN, indicators may be limited to unexplained kernel oopses, panics, Bluetooth subsystem crashes, adapter resets, or recurring disconnect storms. Because no public exploit indicators or known threat actor exploitation are reported, detection should focus on behavioral artifacts and kernel fault signatures rather than malware-specific IOCs.

• BUG: KASAN: slab-use-after-free in l2cap_sock_kill
• slab-use-after-free in l2cap_sock_kill
• l2cap_sock_cleanup_listen
• l2cap_conn_del
• l2cap_chan_del
• l2cap_sock_close_cb
• l2cap_sock_kill
• hci_rx_work
• Bluetooth:
• L2CAP
• kernel BUG at net/bluetooth
• general protection fault
• kernel panic
• Oops:
• KASAN: use-after-free
• bt_accept_dequeue
• release_sock

What your security team should do

• Inventory Linux endpoints and embedded systems with Bluetooth enabled, prioritizing user-facing laptops, workstations, kiosks, and shared systems.
• Patch affected Linux kernels through the relevant distribution or device vendor and reboot promptly after installation.
• Disable Bluetooth on systems that do not require it, especially servers and production appliances.
• Monitor kernel logs for Bluetooth-related use-after-free, KASAN, oops, panic, or repeated HCI disconnect activity.
• Treat unexpected kernel crashes on Bluetooth-capable systems as potentially security-relevant until reviewed.
• For hardened environments, restrict unprivileged access to Bluetooth features and prevent unnecessary Bluetooth module loading.
• Track vendor advisories because fixed versions are distribution-specific and may arrive as backports rather than obvious upstream version changes.