CVE-2026-53253

What it actually does

This flaw is an out-of-bounds read in the Linux kernel Bluetooth BNEP receive path. A Bluetooth BNEP peer can send a malformed, too-short BNEP SDU that causes bnep_rx_frame() or bnep_rx_control() to read fields such as the packet type, control opcode, or setup UUID-size byte before confirming those bytes are present. In instrumented kernels this is reported as a KASAN slab-out-of-bounds read; on production systems the most likely impact is a kernel fault, Bluetooth subsystem instability, or system crash. There is no public evidence of weaponized exploitation, ransomware use, or reliable remote code execution at this time, and the reported EPSS probability is low.

Why it matters to the business

Systems that expose Bluetooth PAN/BNEP functionality could be disrupted by a nearby or connected Bluetooth peer sending malformed frames. The main operational risk is denial of service: affected Linux hosts may lose Bluetooth networking functionality or, in worse cases, experience a kernel crash requiring reboot. Risk is highest for laptops, embedded Linux devices, kiosks, IoT gateways, vehicle/industrial devices, and systems that keep Bluetooth enabled in untrusted physical environments. The vulnerability is not currently in CISA KEV and has low observed exploitation likelihood, but remediation should still be planned for Bluetooth-enabled fleets because exploitation requires only protocol-level malformed input from a BNEP peer.

How an attack unfolds

An attacker positions a Bluetooth-capable device within radio range of a target that has Bluetooth and BNEP/PAN functionality enabled. The attacker establishes or reaches a BNEP interaction path, depending on the target's pairing, PAN, and Bluetooth policy configuration. Instead of sending a well-formed BNEP frame, the attacker sends a short SDU that omits bytes the kernel parser expects to be present. The vulnerable kernel code reads the packet type and, for control packets, additional fields such as the control opcode or setup UUID-size byte before validating the frame length. That invalid read can trigger a kernel memory safety violation, producing KASAN or kernel oops output on debug builds and potentially crashing or destabilizing the host on production builds. Current intelligence does not indicate public exploit maturity, named threat actor use, or ransomware campaign adoption.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the Bluetooth BNEP short-frame validation issue. The fix rejects short frames before parsing by validating fixed fields with skb_pull_data(), ensuring control opcodes and setup UUID-size bytes are present before dereference. Because no exact distribution package versions were provided, use vendor advisories for the deployed distribution or appliance firmware to identify the corrected kernel package. Where immediate patching is not possible, reduce exposure by disabling Bluetooth if it is not required, disabling Bluetooth PAN/BNEP services, blocking or removing untrusted pairings, enforcing strict Bluetooth pairing policies, and limiting use of Bluetooth in untrusted physical locations. For embedded or appliance products, obtain firmware from the device vendor that incorporates the corrected kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version after reboot and comparing it with the vendor advisory for this issue. Validate that Bluetooth remains disabled where mitigation requires it, or that BNEP/PAN services are not available unless explicitly needed. On source-based or custom kernels, verify that the Bluetooth BNEP receive path rejects short frames before parsing fixed fields and that bnep_rx_frame() no longer dereferences packet type, control opcode, or setup UUID-size bytes without successful length validation. Review kernel logs after testing or normal operation for absence of KASAN, oops, BUG, WARNING, or panic messages referencing bnep_rx_frame, bnep_rx_control, or net/bluetooth/bnep/core.c.

Typical attack path

1. Identify a Linux target with Bluetooth enabled and BNEP/PAN support available.
2. Move within Bluetooth radio range or otherwise obtain the ability to communicate as a BNEP peer.
3. Initiate or reach the Bluetooth PAN/BNEP data path according to the target's Bluetooth configuration.
4. Send a malformed short BNEP SDU, such as a truncated control packet or setup connection request.
5. Trigger an out-of-bounds read in the kernel BNEP parser before length validation occurs.
6. Cause Bluetooth subsystem failure, kernel warning/oops, or a system crash depending on kernel build and runtime configuration.

How to detect it

Look for evidence of kernel memory-safety reports, oopses, panics, or Bluetooth subsystem failures occurring around Bluetooth connection or PAN activity. Primary log sources are the kernel ring buffer, system journal, syslog, crash dump storage, kdump/vmcore analysis, endpoint telemetry that captures kernel panics, and Bluetooth service logs such as bluetoothd where available. Search for KASAN slab-out-of-bounds reports referencing bnep_rx_frame, bnep_rx_control, or net/bluetooth/bnep/core.c, especially with call traces involving process_one_work or Bluetooth networking. Also review Bluetooth pairing and connection history for unknown nearby devices or unexpected PAN/BNEP activity before the crash. Because malformed Bluetooth frames may not be logged at packet level by default, absence of network indicators does not rule out exploitation; kernel crash artifacts are the most reliable retrospective signal.

• KASAN slab-out-of-bounds in bnep_rx_frame
• bnep_rx_frame+0x
• bnep_rx_control
• net/bluetooth/bnep/core.c
• Read of size 1
• kmalloc-8 of size 8
• allocated 1-byte region
• BNEP_SETUP_CONN_REQ
• Bluetooth: bnep
• process_one_work
• worker_thread
• kernel BUG at net/bluetooth/bnep/core.c
• Oops:
• Kernel panic

What your security team should do

• Prioritize patching Bluetooth-enabled Linux endpoints, embedded systems, and appliances that operate in public or physically accessible areas.
• Disable Bluetooth or Bluetooth PAN/BNEP on systems where it is not business-critical.
• Inventory Linux assets with Bluetooth hardware and loaded Bluetooth/BNEP kernel modules to determine exposure.
• Monitor kernel logs for crashes or memory-safety reports involving bnep_rx_frame, bnep_rx_control, or net/bluetooth/bnep/core.c.
• Review Bluetooth pairing posture and remove unknown, stale, or unnecessary paired devices.
• For custom kernels or vendor forks, confirm the upstream BNEP short-frame validation patch has been backported.
• Treat unexpected kernel crashes on Bluetooth-enabled systems as potentially security-relevant until logs and Bluetooth activity are reviewed.