CVE-2026-53254

What it actually does

This vulnerability is an out-of-bounds read in the Linux kernel Bluetooth RFCOMM implementation. RFCOMM Multiplexer Control Channel handlers parse attacker-controlled Bluetooth frames and cast packet data to protocol-specific structures before confirming that the packet buffer is long enough. A nearby malicious Bluetooth device can send truncated MCC frames that cause the kernel to read beyond the valid socket buffer contents. The most likely effects are kernel memory disclosure to adjacent parsing logic, kernel warnings or crashes on hardened/debug builds, and Bluetooth subsystem instability. Exploitation requires Bluetooth reachability and an RFCOMM interaction path; pairing or service authorization requirements depend on host Bluetooth configuration and exposed profiles.

Why it matters to the business

Systems with Bluetooth enabled may be exposed to attack from a nearby device, creating risk of device instability, kernel crashes, or limited leakage of kernel memory. The operational impact is highest for laptops, workstations, embedded Linux devices, kiosks, vehicles, medical/industrial systems, and IoT products that keep Bluetooth enabled in public or shared physical spaces. The vulnerability is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, physical-proximity attacks can still be relevant for high-value endpoints and unmanaged Linux-based devices.

How an attack unfolds

An attacker places a Bluetooth-capable device within radio range of a vulnerable Linux system and identifies that the target has Bluetooth enabled and is willing to negotiate RFCOMM-related services. The attacker initiates or reaches an RFCOMM session, depending on the target’s pairing and profile exposure, then sends malformed Multiplexer Control Channel frames whose payloads are shorter than the Linux kernel handler expects. Vulnerable kernels dereference fields from the truncated socket buffer without first validating the full length. This can cause the kernel to read memory beyond the packet buffer, potentially producing kernel diagnostics, Bluetooth stack instability, or a crash on systems with memory-safety instrumentation. There is no provided evidence of public exploit maturity, named threat actor use, ransomware use, or KEV exploitation at this time.

How to fix it

Apply the Linux kernel update that includes the RFCOMM MCC skb length validation fix. Because no exact affected product list or package-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory rather than relying only on upstream version numbers. Prioritize updates on systems where Bluetooth is enabled, portable endpoints, shared-space devices, and embedded Linux products. If immediate patching is not possible, disable Bluetooth, block or remove unnecessary RFCOMM-based profiles and services, require pairing/authorization for Bluetooth services, limit discoverability, and use endpoint/device management controls to keep Bluetooth off except where operationally required.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build containing the RFCOMM fix that validates skb length before dereferencing MCC handler structures. Validate through distribution package metadata, vendor advisories, changelogs, or source inspection for the RFCOMM change using skb_pull_data() in the affected MCC handlers. On representative systems, confirm the running kernel version matches the patched package after reboot. Where feasible in a lab, use Bluetooth protocol fuzzing or malformed RFCOMM MCC test frames against a non-production device to confirm truncated frames are rejected without kernel warnings, KASAN reports, oopses, or Bluetooth service crashes. Also validate that Bluetooth is disabled or restricted on systems where it is not required.

Typical attack path

1. Attacker comes within Bluetooth radio range of a vulnerable Linux device.
2. Attacker discovers that Bluetooth is enabled and probes exposed Bluetooth/RFCOMM services.
3. Attacker establishes or triggers an RFCOMM control-channel interaction, subject to the device’s pairing and authorization policy.
4. Attacker sends truncated RFCOMM MCC frames such as malformed RPN or related control messages.
5. The vulnerable kernel RFCOMM handler parses the frame and reads beyond the available socket buffer data.
6. The target may expose adjacent kernel memory to parsing behavior, emit kernel memory-safety warnings, disrupt Bluetooth services, or crash/restart depending on kernel configuration and hardening.

How to detect it

Retrospective detection is difficult because malformed Bluetooth frames may not be logged by default and exploitation occurs over short-range radio rather than ordinary IP network telemetry. Review kernel logs, system journals, crash dumps, and endpoint telemetry for Bluetooth/RFCOMM-related kernel warnings, KASAN reports, oopses, panic events, or repeated Bluetooth subsystem resets around times when devices were in public or shared spaces. On systems with Bluetooth monitoring enabled, inspect btmon, HCI snoop logs, or equivalent captures for malformed or unusually short RFCOMM Multiplexer Control Channel frames, especially truncated RPN or other MCC commands. Correlate suspicious kernel events with Bluetooth adapter activity, new or unknown paired devices, failed pairing attempts, sudden RFCOMM connections, and unexplained restarts of bluetoothd or kernel Bluetooth modules. Because there are no known named threat actors, KEV activity, or public exploit indicators provided, focus detection on behavioral artifacts rather than actor-specific infrastructure.

• BUG: KASAN: slab-out-of-bounds in rfcomm_recv_rpn
• BUG: KASAN: slab-out-of-bounds in rfcomm_recv_msc
• BUG: KASAN: slab-out-of-bounds in rfcomm_recv_rls
• BUG: KASAN: slab-out-of-bounds in rfcomm_recv_pn
• BUG: KASAN: out-of-bounds in rfcomm_recv_rpn
• BUG: KASAN: out-of-bounds in rfcomm_recv_msc
• BUG: KASAN: out-of-bounds in rfcomm_recv_rls
• BUG: KASAN: out-of-bounds in rfcomm_recv_pn
• kernel BUG at net/bluetooth/rfcomm/core.c
• Oops: .*rfcomm_recv_rpn
• Oops: .*rfcomm_recv_msc
• Oops: .*rfcomm_recv_rls
• Oops: .*rfcomm_recv_pn
• general protection fault.*rfcomm_recv_rpn
• general protection fault.*rfcomm_recv_msc
• general protection fault.*rfcomm_recv_rls
• general protection fault.*rfcomm_recv_pn
• Bluetooth: RFCOMM
• rfcomm_recv_rpn
• rfcomm_recv_msc
• rfcomm_recv_rls
• rfcomm_recv_pn

What your security team should do

• Inventory Linux systems with Bluetooth hardware and determine where Bluetooth is enabled, discoverable, or exposing RFCOMM-based services.
• Patch affected Linux kernels using vendor-provided fixed packages, prioritizing mobile endpoints, public-facing workstations, embedded devices, and high-value systems used in shared physical spaces.
• Where patching is delayed, disable Bluetooth or enforce strict pairing, non-discoverable mode, and removal of unnecessary Bluetooth profiles.
• Monitor kernel logs for Bluetooth RFCOMM parsing errors, kernel oopses, KASAN out-of-bounds read reports, and unexplained Bluetooth service resets.
• Update vulnerability management logic to track vendor backported kernel fixes, since the fixed version may differ by distribution.
• For managed endpoints, enforce Bluetooth configuration baselines and alert when Bluetooth is re-enabled outside approved use cases.
• Treat any kernel crash or KASAN report referencing RFCOMM MCC receive handlers as a potential attempted proximity exploit and preserve logs for forensic review.