CVE-2026-5068: Bluetooth L2CAP Buffer Overflow Vulnerability

CVE-2026-5068 Overview

CVE-2026-5068 is a 2-byte out-of-bounds write vulnerability in the Zephyr RTOS Bluetooth host stack. The flaw resides in the Logical Link Control and Adaptation Protocol (L2CAP) LE Credit-Based Connection (CoC) Service Data Unit (SDU) reassembly logic in subsys/bluetooth/host/l2cap.c. A remote, unauthenticated Bluetooth Low Energy (BLE) peer within radio range can trigger the condition when the application enables segmentation through chan_ops.alloc_buf and the configured RX pool has a user_data_size smaller than 2 bytes. The out-of-bounds write occurs in l2cap_chan_le_recv_seg when the segmentation counter is written into the net_buf user_data area. This issue is classified under [CWE-787] Out-of-Bounds Write.

Critical Impact
An adjacent, unauthenticated BLE attacker can corrupt heap memory in the Bluetooth host, producing fatal errors or potential memory corruption on embedded devices running affected Zephyr builds.

Affected Products

Zephyr RTOS Bluetooth host stack
Applications using L2CAP LE CoC with chan_ops.alloc_buf segmentation
Embedded systems with RX pools configured with user_data_size < 2 bytes

Discovery Timeline

2026-06-09 - CVE-2026-5068 published to NVD
2026-06-09 - Last updated in NVD database

Technical Details for CVE-2026-5068

Vulnerability Analysis

The vulnerability occurs during L2CAP LE Credit-Based Connection SDU reassembly inside the Zephyr Bluetooth host. When an application provides a custom buffer allocator via chan_ops.alloc_buf to support segmentation, the host stores a per-buffer segmentation counter in the net_buf user_data region. The l2cap_chan_le_recv_seg function writes that counter without verifying the size of the user_data area in the RX pool. If the pool was configured with a user_data_size smaller than 2 bytes, the write extends past the allocated user_data area into adjacent heap memory. Observed effects include an AddressSanitizer (ASan) abort during fuzzing and, on production builds without ASan, heap corruption or a fatal kernel error.

Root Cause

The root cause is missing validation of the destination buffer's user_data_size before writing the segmentation counter. The host stack assumes the application-provided RX pool has at least 2 bytes of user_data, but this invariant is not enforced in l2cap_chan_le_recv_seg. When a misconfigured pool is supplied, the unchecked 2-byte write corrupts memory immediately following the user_data field.

Attack Vector

The attack vector is adjacent network access over BLE. An unauthenticated peer within Bluetooth radio range establishes an L2CAP LE CoC channel and transmits segmented SDUs that drive the reassembly code path. No user interaction is required. Exploitation depends on the target application enabling segmentation via chan_ops.alloc_buf and configuring an undersized RX pool. The vulnerability manifests during normal protocol processing rather than requiring malformed packets. See the Zephyr GitHub Security Advisory GHSA-qrcq-hxwj-mqxm for protocol-level details.

Detection Methods for CVE-2026-5068

Indicators of Compromise

Unexpected fatal errors or kernel panics on BLE-enabled Zephyr devices following L2CAP LE CoC traffic
AddressSanitizer aborts referencing l2cap_chan_le_recv_seg in instrumented builds
Heap corruption traces or net_buf metadata inconsistencies in crash dumps

Detection Strategies

Audit application code for calls to chan_ops.alloc_buf and verify the RX pool's user_data_size is at least 2 bytes
Build firmware with AddressSanitizer or Zephyr's memory guard configurations to surface out-of-bounds writes during testing
Fuzz L2CAP LE CoC endpoints with segmented SDUs to reproduce the reassembly path under controlled conditions

Monitoring Recommendations

Collect and review device crash logs centrally to identify clusters of Bluetooth-related fatal errors
Monitor BLE pairing and L2CAP channel establishment events from untrusted peers in proximity to deployed devices
Track firmware versions in inventory systems to confirm patched Zephyr builds are deployed across the fleet

How to Mitigate CVE-2026-5068

Immediate Actions Required

Identify all firmware images that use the Zephyr Bluetooth host with L2CAP LE CoC segmentation enabled
Audit every custom chan_ops.alloc_buf implementation and ensure the backing net_buf pool defines user_data_size of at least 2 bytes
Apply the upstream fix referenced in the Zephyr Security Advisory GHSA-qrcq-hxwj-mqxm and rebuild affected firmware

Patch Information

The Zephyr project has published a security advisory and fix at GHSA-qrcq-hxwj-mqxm. Rebase affected branches onto the patched Zephyr release and redeploy firmware to all BLE-capable devices. Verify the fix enforces a minimum user_data_size check before writing the segmentation counter in l2cap_chan_le_recv_seg.

Workarounds

Disable L2CAP LE CoC segmentation by not registering a chan_ops.alloc_buf callback if the feature is not required
Reconfigure existing RX net_buf pools to allocate a user_data_size of at least 2 bytes to satisfy the segmentation counter write
Restrict BLE advertising and accept connections only from bonded peers to reduce exposure until firmware is patched

bash

# Configuration example: ensure net_buf pool user_data_size >= 2 bytes
# In your Zephyr application source:
NET_BUF_POOL_DEFINE(rx_pool, RX_BUF_COUNT, RX_MTU, sizeof(uint16_t), NULL);