CVE-2026-53256

What it actually does

This is a Linux kernel use-after-free race in the Bluetooth RFCOMM implementation. During inbound RFCOMM connection handling, the kernel can locate a listening RFCOMM socket, drop the global socket-list lock without holding a reference to that listener, and then continue using the listener while another thread closes and frees it. If the close path wins the race, subsequent operations such as lock_sock(), bt_accept_enqueue(), or state-change notification may dereference freed kernel memory. The observed failure mode is a kernel slab use-after-free, and the practical impact is most likely local or nearby Bluetooth-triggered denial of service through kernel crash; depending on kernel configuration, heap state, and exploitability of the race, memory corruption could theoretically create a path toward privilege escalation or kernel code execution, but no public exploit maturity is indicated.

Why it matters to the business

Systems with Bluetooth enabled and vulnerable kernel builds may be exposed to crashes or instability when handling RFCOMM Bluetooth connection activity. For workstations, laptops, embedded Linux devices, kiosks, industrial gateways, or appliances that rely on Bluetooth, this can cause service interruption, device reboot, or degraded availability. The current exploitation likelihood appears low based on the supplied EPSS score and absence from the Known Exploited Vulnerabilities catalog, but kernel memory-safety issues should still be prioritized where Bluetooth is enabled, externally reachable over short range, or present on high-availability devices.

How an attack unfolds

An attacker would need to reach the vulnerable Bluetooth RFCOMM code path, typically by being within Bluetooth radio range of a target with Bluetooth enabled and RFCOMM support active. The attacker initiates or manipulates RFCOMM connection attempts while the target listener socket is concurrently being closed. The vulnerable code looks up the listener under a lock but fails to retain a reference before releasing that lock. If the listener is closed and freed at the right moment, the connection indication path continues using a stale pointer. Successful exploitation requires winning a timing race, shaping kernel heap state, and triggering the freed listener to be reused or accessed in a useful way. The most reliable outcome is likely a kernel panic or crash; more advanced exploitation would require converting the use-after-free into controlled memory corruption.

How to fix it

Apply the vendor-provided Linux kernel update that includes the RFCOMM fix: taking a reference on the listener before releasing the RFCOMM socket-list lock, rechecking that the socket is still in BT_LISTEN state before queueing a child socket, caching deferred-setup state while locked, and dropping the reference after the final parent use. Because no exact package fixed versions were supplied, use the fixed kernel version from the relevant Linux distribution, appliance vendor, or upstream stable kernel advisory. Where immediate patching is not possible, reduce exposure by disabling Bluetooth, disabling unused RFCOMM/SPP services, blocking automatic Bluetooth service startup, removing unnecessary Bluetooth packages or kernel modules where operationally safe, and restricting physical/radio proximity to sensitive systems. Reboot into the updated kernel after installation; merely installing the package is insufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor release containing the Bluetooth RFCOMM listener reference fix. Validate with commands such as uname -a, distribution package tooling, and vendor security advisory mappings. Check that Bluetooth is disabled or RFCOMM services are unavailable on systems where mitigation rather than patching was chosen. On Linux systems with debug or test kernels, exercise RFCOMM connection and listener close paths and confirm there are no KASAN, slab, use-after-free, kernel oops, or panic messages involving rfcomm_connect_ind(), lock_sock_nested(), rfcomm_sock_release(), or rfcomm_sock_kill(). For fleet validation, inventory Bluetooth-capable Linux assets, compare their running kernel versions to fixed vendor versions, and verify a reboot occurred after patch deployment.

Typical attack path

1. Identify a Linux target with Bluetooth enabled and reachable over Bluetooth radio range.
2. Probe or interact with RFCOMM-capable Bluetooth services on the target.
3. Trigger inbound RFCOMM connection handling while causing or racing listener socket teardown conditions.
4. Win the race where rfcomm_connect_ind() uses a listener socket after rfcomm_sock_release() and rfcomm_sock_kill() have freed it.
5. Cause a kernel use-after-free that may result in a crash, denial of service, or potentially exploitable memory corruption under favorable conditions.

How to detect it

Review kernel logs, system journals, crash dumps, and endpoint telemetry for evidence of Bluetooth RFCOMM-related kernel faults. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore artifacts, kernel oops/panic records, EDR kernel-crash telemetry, and Bluetooth daemon logs where available. Look for KASAN or allocator reports showing slab-use-after-free or use-after-free in lock_sock_nested() called from rfcomm_connect_ind(), with freeing stacks involving rfcomm_sock_kill(), rfcomm_sock_release(), or rfcomm_sock_shutdown(). Also investigate unexpected reboots or kernel panics temporally associated with Bluetooth pairing, RFCOMM/SPP activity, nearby unknown Bluetooth devices, or repeated inbound Bluetooth connection attempts. There are no reliable remote network IOCs for this flaw because exploitation occurs over Bluetooth and manifests primarily as kernel memory corruption or crash telemetry rather than conventional IP traffic.

• KASAN: slab-use-after-free
• BUG: KASAN: slab-use-after-free
• use-after-free in lock_sock_nested
• lock_sock_nested
• rfcomm_connect_ind
• rfcomm_sock_kill
• rfcomm_sock_release
• rfcomm_sock_shutdown
• bt_accept_enqueue
• Bluetooth: RFCOMM
• kernel BUG at net/bluetooth/rfcomm
• Oops:
• Kernel panic
• general protection fault
• Unable to handle kernel paging request

What your security team should do

• Inventory Linux systems with Bluetooth hardware, Bluetooth enabled, or RFCOMM/SPP services in use, prioritizing laptops, kiosks, embedded devices, appliances, and physically accessible systems.
• Patch affected Linux kernels through the appropriate distribution or vendor channel and reboot into the fixed kernel.
• If patching is delayed, disable Bluetooth or remove/blacklist unused Bluetooth/RFCOMM functionality where operationally feasible.
• Prioritize remediation for devices in public, shared, or uncontrolled physical locations because exploitation requires Bluetooth proximity in typical scenarios.
• Monitor kernel logs for Bluetooth RFCOMM crashes, KASAN reports, slab use-after-free messages, kernel oops events, and unexpected reboots.
• Treat any kernel crash involving rfcomm_connect_ind(), lock_sock_nested(), rfcomm_sock_kill(), or rfcomm_sock_release() as suspicious until correlated with benign testing or known hardware instability.
• Track vendor advisories for exact fixed kernel package versions because none were supplied in the input.