CVE-2026-43062

What it actually does

This is a Linux kernel Bluetooth L2CAP logic flaw in Enhanced Credit Based Flow Control reconfiguration handling. The vulnerable code parses an incoming L2CAP_ECRED_RECONF_RSP packet as the wrong response structure, causing the kernel to require an incorrect packet length and read the result field from the wrong offset. A nearby unauthenticated Bluetooth attacker can send crafted L2CAP traffic that causes valid reconfiguration responses to be rejected or causes the kernel to act on attacker-controlled or incorrect result data. The primary impact is protocol state corruption and integrity impact to Bluetooth L2CAP channel handling, with potential disruption of Bluetooth communications.

Why it matters to the business

Systems with enabled Bluetooth may be exposed to attacks from physically nearby adversaries, such as someone within radio range in an office, public area, vehicle, factory floor, or medical/retail environment. Successful exploitation could disrupt Bluetooth-dependent workflows or interfere with devices relying on Bluetooth connectivity. The CVSS score is high, but current public exploitation signals are low: EPSS is approximately 0.00215, unchanged over 30 days, it is not listed in CISA KEV, and no mature exploit is reported. Organizations with broad Linux endpoint, embedded, IoT, kiosk, automotive, or industrial Bluetooth usage should still prioritize remediation because kernel Bluetooth flaws are difficult to monitor and exposure depends heavily on physical proximity controls.

How an attack unfolds

An attacker must be within Bluetooth radio range of a vulnerable Linux system with Bluetooth enabled. The attacker initiates or interacts with L2CAP Enhanced Credit Based Flow Control behavior and sends a crafted ECRED reconfiguration response. Because the kernel uses the connection-response structure instead of the reconfiguration-response structure, the vulnerable handler validates the wrong packet size and reads the result value from the wrong offset. By controlling the packet layout, the attacker can cause legitimate reconfiguration responses to be rejected or cause the kernel to process an incorrect result value. This can corrupt expected L2CAP channel state or disrupt Bluetooth communication. There is no indication from the provided intelligence that this issue is remotely exploitable over IP networks, used in ransomware campaigns, or actively exploited by named threat actors.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the fix for the Bluetooth L2CAP l2cap_ecred_reconf_rsp() type confusion. Because no exact fixed package versions were provided, use the security advisory or changelog from the operating system, appliance, or embedded Linux vendor to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, blocking automatic Bluetooth service startup, limiting pairing/discoverability, removing unnecessary Bluetooth profiles, and enforcing physical proximity controls in sensitive areas. For embedded or appliance products, obtain firmware from the vendor that incorporates the corrected kernel Bluetooth stack.

How to confirm the fix worked

Confirm that systems are running a kernel build whose vendor changelog includes the Bluetooth L2CAP ECRED reconfiguration response fix or references CVE-2026-43062. Validate that Bluetooth is disabled on systems where it is not operationally required. On representative patched systems, confirm the loaded kernel version matches the remediated package and that the Bluetooth stack continues to function with expected devices. For source-based kernels, confirm that l2cap_ecred_reconf_rsp() uses struct l2cap_ecred_reconf_rsp for the response parsing and validates the correct 2-byte response length rather than the 8-byte ECRED connection-response structure.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and within radio range.
2. Establish Bluetooth proximity and interact with the target’s L2CAP stack.
3. Trigger L2CAP Enhanced Credit Based Flow Control reconfiguration handling.
4. Send a crafted L2CAP_ECRED_RECONF_RSP packet with length and field placement chosen to exploit the incorrect structure parsing.
5. Cause the vulnerable kernel to reject valid responses or read the result field from the wrong packet offset.
6. Disrupt or manipulate Bluetooth L2CAP channel behavior.

How to detect it

Detection is challenging because exploitation occurs over Bluetooth radio rather than normal IP network paths and may not leave conventional firewall or proxy logs. Review kernel logs, system journals, Bluetooth service logs, EDR telemetry, and Bluetooth packet captures for unusual L2CAP Enhanced Credit Based Flow Control activity, repeated ECRED reconfiguration failures, unexpected Bluetooth disconnects, or protocol errors occurring near the same time. Useful log sources include systemd journal, dmesg/kern.log, bluetoothd logs, audit/EDR process telemetry around Bluetooth utilities, and btmon or HCI snoop captures where available. In packet captures, look for L2CAP ECRED reconfiguration response traffic with abnormal lengths or unexpected result values. Because exploitation requires radio proximity, correlate suspicious Bluetooth errors with physical access events, unknown nearby Bluetooth devices, or reports of intermittent Bluetooth failures. There are no public threat-actor-specific indicators provided for this vulnerability.

• l2cap_ecred_reconf_rsp
• L2CAP_ECRED_RECONF_RSP
• ECRED_RECONF_RSP
• Bluetooth: L2CAP
• L2CAP_ECRED
• -EPROTO
• btmon
• bluetoothd

What your security team should do

• Inventory Linux endpoints, servers, appliances, embedded systems, and IoT devices with Bluetooth enabled.
• Prioritize patching systems where Bluetooth is enabled in public, shared, mobile, or physically accessible locations.
• Apply the vendor kernel or firmware update containing the corrected Bluetooth L2CAP ECRED reconfiguration handling.
• Disable Bluetooth wherever it is not required, especially on servers and fixed-function systems.
• Review Bluetooth pairing, discoverability, and profile exposure policies to reduce opportunities for nearby attackers.
• Monitor kernel, Bluetooth daemon, EDR, and Bluetooth packet-capture telemetry for repeated L2CAP ECRED errors or anomalous reconfiguration traffic.
• For high-risk environments, consider periodic Bluetooth radio sweeps or monitoring for unknown devices near sensitive Linux assets.