CVE-2026-43134: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ
This adds a check for encryption key size upon receiving
L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which
expects L2CAP_CR_LE_BAD_KEY_SIZE.
Security readout for executives and security teams
Plain-English summary
A nearby attacker may reach a Linux device over Bluetooth Low Energy without credentials or user interaction. The kernel failed to reject certain L2CAP connection requests using an inadequate encryption key size. The supplied CVSS assessment indicates potentially serious confidentiality and integrity impact, although the sources do not describe a demonstrated end-to-end attack.
Executive priority
Treat this as a high-priority proximity risk, especially for mobile, embedded, kiosk, and publicly accessible Linux devices using Bluetooth. Schedule vendor-supported kernel updates promptly, but do not assume internet-wide exposure. Escalate systems handling sensitive data where nearby untrusted persons could obtain Bluetooth reach.
Technical view
Linux L2CAP handling omitted the encryption-key-size check when processing L2CAP_LE_CONN_REQ. The correction returns L2CAP_CR_LE_BAD_KEY_SIZE as required by the cited Bluetooth conformance test. CVSS 3.1 is 8.1 with adjacent access, low complexity, no privileges, no interaction, high confidentiality and integrity impact, and no availability impact.
Likely exposure
Exposure is most plausible on affected Linux systems with Bluetooth Low Energy enabled and reachable by a nearby attacker. The supplied affected-version metadata spans multiple kernel branches but is insufficiently structured to determine precise vulnerable ranges reliably. Confirm status using the running distribution kernel and its vendor guidance.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation or a public exploit. The adjacent-network vector limits attacks to Bluetooth proximity or equivalent radio reach. No prerequisites beyond reachability are established by the supplied CVSS vector, but practical attack outcomes are not documented.
Researcher notes
The evidence establishes a missing key-size validation and its expected protocol rejection result. It does not identify a CWE, minimum accepted key size, proof of concept, observed exploitation, or detailed compromise mechanism. Multiple stable commits indicate branch-specific backports; validate package ancestry rather than comparing version strings alone.
Mitigation direction
Update to a vendor-supported kernel containing the applicable referenced stable fix.
Check distribution security guidance to map packaged kernel versions to the upstream fixes.
Prioritize Bluetooth-enabled endpoints operating in public, shared, or physically accessible locations.
If updates are delayed, follow vendor guidance for reducing unnecessary Bluetooth exposure.
Validation and detection
Inventory Linux endpoints with Bluetooth Low Energy enabled or required.
Record each running kernel and distribution package version.
Confirm the vendor package incorporates an applicable referenced kernel commit.
Retest Bluetooth-dependent services after updating the kernel.
Monitor vendor advisories because the supplied version boundaries are ambiguous.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43134 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
9Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.