Go to file
Lu Jia eeadab36e1 a2dp: Fix use-after-free on ACP disconnect during CONFIGURED state
bug: v/88938

When acting as A2DP ACP, if the remote side disconnects ACL right after
Set Configuration (before media channel is established), a2dp_info->stream
is freed in a2dp_info_destroy() while zblue's ep->stream still references
the same memory. The subsequent avdtp_release_work() then accesses freed
memory (use-after-free).

Fix by deferring a2dp_info cleanup in zblue_on_disconnected() when stream
is still alive. The cleanup is completed later in zblue_on_stream_released()
after zblue finishes its release work.

Also guard DISCONNECTED_EVT in zblue_on_stream_released() to only fire
when media channel was actually established, avoiding duplicate events
with zblue_on_disconnected().

Add debug logging to a2dp_info_destroy, zblue_on_stream_configured,
zblue_on_stream_released, and zblue_on_disconnected for easier diagnosis.

Signed-off-by: Lu Jia <jialu@xiaomi.com>
2026-04-27 23:14:56 +08:00
.gitee add .github/CODEOWNERS PULL_REQUEST_TEMPLATE.md 2026-04-27 23:14:50 +08:00
.github update workflow files 2026-04-27 23:14:54 +08:00
debug bluetooth: add bt trace tool 2026-04-20 14:51:53 +08:00
dfx bluetooth: add dfx in android. 2026-04-27 23:14:54 +08:00
feature bt_uuid: define BT_UUID_STR_LENGTH macro and update usages 2026-04-27 23:14:55 +08:00
framework bt_uuid: define BT_UUID_STR_LENGTH macro and update usages 2026-04-27 23:14:55 +08:00
img Doc: add introduction to Bluetooth 2026-04-20 14:51:17 +08:00
sample_code bluetooth: add sample adapter state debug 2026-04-20 14:52:44 +08:00
service a2dp: Fix use-after-free on ACP disconnect during CONFIGURED state 2026-04-27 23:14:56 +08:00
tests Clang-format: Update format of all files based on new .clang-format 2026-04-20 14:50:50 +08:00
tools bluetooth/tools: fix bttool cleanup failure on BT disable 2026-04-27 23:14:55 +08:00
.clang-format Clang-format: Remove all customization and fall back to the default WebKit style 2026-04-20 14:50:43 +08:00
.gitignore update gap & btservice interface 2026-04-20 14:48:58 +08:00
Android.bp bluetooth: add dfx in android. 2026-04-27 23:14:54 +08:00
CMakeLists.txt cmake: add CONFIG_BLUETOOTH_LE_CS build support 2026-04-27 23:14:55 +08:00
Kconfig gattc: refactor to use debug module and add build config 2026-04-27 23:14:55 +08:00
LICENSE add ci.yml 2026-04-27 23:14:50 +08:00
Make.defs Merge commit 2026-04-27 23:14:50 +08:00
Makefile gattc: refactor to use debug module and add build config 2026-04-27 23:14:55 +08:00
Makefile.host service/socket: add lightweight socket ipc layer 2026-04-20 14:50:05 +08:00
README.md Doc: Remove QuickAPP API details 2026-04-27 23:14:50 +08:00
README_zh-cn.md Doc: Remove QuickAPP API details 2026-04-27 23:14:50 +08:00
frameworkBluetooth.go Merge commit 2026-04-27 23:14:50 +08:00
frameworkBluetoothBin.go bluetooth: add android15 config control. 2026-04-20 14:53:23 +08:00
test.py service/socket: add lightweight socket ipc layer 2026-04-20 14:50:05 +08:00

README.md

Overview of openvela Bluetooth

 English | [简体中文](README_zh-cn.md) 

1. Introduction to openvela Bluetooth

openvela Bluetooth has been certified for Bluetooth 5.4. It currently supports Bluetooth profiles listed as below:

  • Core

    • BR/EDR/BLE
    • GAP
    • L2CAP
    • GATT Client/Server
  • A2DP SRC/SNK

  • AVRCP CT/TG

  • HFP AG/HF

  • PAN

  • SPP

  • HID

  • HOGP

  • LEA

    • TMAP
    • CAP
    • BAP/ASCS/PACS/BASS
    • CSIP/CSIS
    • MCP/MCS
    • CCP/TBS
    • VCP/VCS
  • Mesh

openvela Bluetooth currently also supports a variety of open source and proprietary stacks such as Zephyr, Bluez, Bluedroid, Barrot, etc.

2. openvela Bluetooth Application Development

Third-party application developers may utilize the openvela QuickApp Feature to acquire system access capabilities.

Additionally, NDK interfaces are also provided to utilize all Bluetooth system-level capabilities. Please refer to header files in folder framework/include for more details.

3. openvela Bluetooth Driver Development

openvela Bluetooth supports multiple driver architectures. Taking the widely used BTH4 driver architecture as an example, chip manufacturers can implement a variable of the struct bt_driver_s structure type, and initialize the following member functions for it.

  • CODE int (*open)(FAR struct bt_driver_s *btdev);
  • CODE int (*send)(FAR struct bt_driver_s *btdev, enum bt_buf_type_e type, FAR void *data, size_t len);
  • CODE int (*ioctl)(FAR struct bt_driver_s *btdev, int cmd, unsigned long arg);
  • CODE void (*close)(FAR struct bt_driver_s *btdev);

The implementation of the above member functions depends on the specific type of HCI utilized, which refers to the physical bus linking the Host and the Controller.

Then, register the driver instance by passing the variable of the above structure type via the API bt_driver_register().

  • int bt_driver_register(FAR struct bt_driver_s *drv);

Please refer to the type definition in header file nuttx/include/nuttx/wireless/bluetooth/bt_driver.h. The figure below helps to provide a comprehensive understanding of its functioning within the openvela OS.

Note: chip manufacturers are not required to implement the receive() member function, for it will be initialized by the BTH4 driver.

  • CODE int (*receive)(FAR struct bt_driver_s *btdev, enum bt_buf_type_e type, FAR void *data, size_t len);

Upon receipt of HCI data from the chip, the vendor drivers should invoke the bt_netdev_receive() function, which in turn will trigger the receive() function to store the received HCI data.