Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suspected unaligned access in Bluetooth controller connection handling #50689

Closed
Andrewpini opened this issue Sep 27, 2022 · 0 comments · Fixed by #50845
Closed

Suspected unaligned access in Bluetooth controller connection handling #50689

Andrewpini opened this issue Sep 27, 2022 · 0 comments · Fixed by #50845
Assignees
Labels
area: Bluetooth Controller area: Bluetooth LLCP area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@Andrewpini
Copy link
Collaborator

Andrewpini commented Sep 27, 2022

Describe the bug
The zephyr mesh sample crashes with default settings. The crash seems to occur due to a unaligned memory access in the bluetooth controller handling.

To Reproduce

  1. cd samples/bluetooth/mesh
  2. west build -b < dev > -p (Tested with dev: nrf52840dk_nrf52840)
  3. west flash --erase
  4. Open a terminal program to view the device output.
  5. Provision the device over GATT (E.g https://www.nordicsemi.com/Products/Development-tools/nrf-mesh)

Expected behavior
Expect the terminal to show "USAGE FAULT, Unaligned memory access"

Impact
Chrashes the device.

Workaround
Adding CONFIG_BT_LL_SW_LLCP_LEGACY=y to the prj.conf seems to rectify the issue.

Logs and console output

Terminal Output:

*** Booting Zephyr OS build v3.2.0-rc3-41-g489e8eb02c2a ***
Initializing...
Bluetooth initialized
Mesh initialized
[00:00:00.405,456] fs_nvs: 8 Sectors of 4096 bytes
[00:00:00.405,487] fs_nvs: alloc wra: 0, fe8
[00:00:00.405,487] fs_nvs: data wra: 0, 0
[00:00:00.407,012] bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.407,043] bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.407,073] bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 3.2 Build 0
[00:00:00.407,379] bt_hci_core: No ID address. App must call settings_load()
[00:00:00.409,851] bt_hci_core: Identity: FF:E7:AE:2F:E9:13 (random)
[00:00:00.409,881] bt_hci_core: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1
[00:00:00.409,912] bt_hci_core: LMP: version 5.3 (0x0c) subver 0xffff
[00:00:00.410,125] bt_mesh_prov_device: Device UUID: 00000000-0000-0000-9d24-06ed8899535e
[00:00:20.346,832] bt_mesh_main: Primary Element: 0x0004
[00:00:20.346,862] bt_mesh_main: bt_mesh_provision: net_idx 0x0000 flags 0x00 iv_index 0x0000
[00:00:20.969,909] os: ***** USAGE FAULT *****
[00:00:20.969,909] os: Unaligned memory access
[00:00:20.969,940] os: r0/a1: 0x20001f48 r1/a2: 0x00000001 r2/a3: 0x00000000
[00:00:20.969,970] os: r3/a4: 0xffffffff r12/ip: 0x00000000 r14/lr: 0x0001e9f9
[00:00:20.969,970] os: xpsr: 0x2100001b
[00:00:20.969,970] os: Faulting instruction address (r15/pc): 0x0001e9fc
[00:00:20.970,031] os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:20.970,031] os: Fault during interrupt handling
[00:00:20.970,062] os: Current thread: 0x20002090 (unknown)
[00:00:21.211,120] os: Halting system

We take note of the faulting instruction address 0x0001e9fc. We can find this again in the zephyr.lst

Snippout from zephyr.lst

0001e9ac <lp_cu_send_conn_param_req.isra.0>:
static void lp_cu_send_conn_param_req(struct ll_conn *conn, struct proc_ctx *ctx, uint8_t evt,
1e9ac: e92d 41f0 stmdb sp!, {r4, r5, r6, r7, r8, lr}
return conn_upd_curr && (conn_upd_curr != conn);
1e9b0: 4f24 ldr r7, [pc, # 144] ; (1ea44 <lp_cu_send_conn_param_req.isra.0+0x98>)
1e9b2: 683b ldr r3, [r7, # 0]
1e9b4: 4605 mov r5, r0
1e9b6: 460c mov r4, r1
1e9b8: b12b cbz r3, 1e9c6 <lp_cu_send_conn_param_req.isra.0+0x1a>
if (cpr_active_is_set(conn) || llcp_lr_ispaused(conn) ||
1e9ba: 4298 cmp r0, r3
1e9bc: d003 beq.n 1e9c6 <lp_cu_send_conn_param_req.isra.0+0x1a>
ctx->state = LP_CU_STATE_WAIT_TX_CONN_PARAM_REQ;
1e9be: 2301 movs r3, # 1
1e9c0: 72a3 strb r3, [r4, # 10]
}
1e9c2: e8bd 81f0 ldmia.w sp!, {r4, r5, r6, r7, r8, pc}
if (cpr_active_is_set(conn) || llcp_lr_ispaused(conn) ||
1e9c6: 4628 mov r0, r5
1e9c8: f00e fe20 bl 2d60c <llcp_lr_ispaused>
1e9cc: 2800 cmp r0, # 0
1e9ce: d1f6 bne.n 1e9be <lp_cu_send_conn_param_req.isra.0+0x12>
llcp_rr_get_collision(conn) || !llcp_tx_alloc_peek(conn, ctx)) {
1e9d0: 4628 mov r0, r5
1e9d2: f00f f91d bl 2dc10 <llcp_rr_get_collision>
if (cpr_active_is_set(conn) || llcp_lr_ispaused(conn) ||
1e9d6: 4606 mov r6, r0
1e9d8: 2800 cmp r0, # 0
1e9da: d1f0 bne.n 1e9be <lp_cu_send_conn_param_req.isra.0+0x12>
llcp_rr_get_collision(conn) || !llcp_tx_alloc_peek(conn, ctx)) {
1e9dc: 4621 mov r1, r4
1e9de: 4628 mov r0, r5
1e9e0: f7ff f8ec bl 1dbbc <llcp_tx_alloc_peek>
1e9e4: 2800 cmp r0, # 0
1e9e6: d0ea beq.n 1e9be <lp_cu_send_conn_param_req.isra.0+0x12>
uint16_t event_counter = ull_conn_event_counter(conn);
1e9e8: 4628 mov r0, r5
1e9ea: f00e fbf6 bl 2d1da <ull_conn_event_counter>
llcp_rr_set_incompat(conn, INCOMPAT_RESOLVABLE);
1e9ee: 2101 movs r1, # 1
uint16_t event_counter = ull_conn_event_counter(conn);
1e9f0: 4680 mov r8, r0
llcp_rr_set_incompat(conn, INCOMPAT_RESOLVABLE);
1e9f2: 4628 mov r0, r5
1e9f4: f00f f909 bl 2dc0a <llcp_rr_set_incompat>
ctx->data.cu.offset1 = 0xffffU;
1e9f8: f04f 33ff mov.w r3, # 4294967295
ctx->data.cu.offset3 = 0xffffU;
1e9fc: e9c4 330d strd r3, r3, [r4, # 52] ; 0x34
ctx->data.cu.offset5 = 0xffffU;
1ea00: 87a3 strh r3, [r4, # 60] ; 0x3c
ctx->data.cu.reference_conn_event_count = event_counter;
1ea02: f8a4 8030 strh.w r8, [r4, # 48] ; 0x30
ctx->data.cu.preferred_periodicity = 0U;
1ea06: f884 602e strb.w r6, [r4, # 46] ; 0x2e
ctx->data.cu.offset0 = 0x0000U;
1ea0a: 8666 strh r6, [r4, # 50] ; 0x32
lp_cu_tx(conn, ctx, PDU_DATA_LLCTRL_TYPE_CONN_PARAM_REQ);
1ea0c: 220f movs r2, # 15
1ea0e: 4621 mov r1, r4
1ea10: 4628 mov r0, r5
conn_upd_curr = conn;
1ea12: 603d str r5, [r7, # 0]
1ea14: f7ff feaa bl 1e76c <lp_cu_tx>
switch (conn->lll.role) {
1ea18: f895 3039 ldrb.w r3, [r5, # 57] ; 0x39
1ea1c: 09db lsrs r3, r3, # 7
1ea1e: d002 beq.n 1ea26 <lp_cu_send_conn_param_req.isra.0+0x7a>
ctx->state = LP_CU_STATE_WAIT_RX_CONN_UPDATE_IND;
1ea20: 2304 movs r3, # 4
1ea22: 8163 strh r3, [r4, # 10]
break;
1ea24: e7cd b.n 1e9c2 <lp_cu_send_conn_param_req.isra.0+0x16>
LL_ASSERT(0);
1ea26: 4a08 ldr r2, [pc, # 32] ; (1ea48 <lp_cu_send_conn_param_req.isra.0+0x9c>)
1ea28: 4908 ldr r1, [pc, # 32] ; (1ea4c <lp_cu_send_conn_param_req.isra.0+0xa0>)
1ea2a: 4809 ldr r0, [pc, # 36] ; (1ea50 <lp_cu_send_conn_param_req.isra.0+0xa4>)
1ea2c: f240 1367 movw r3, # 359 ; 0x167
1ea30: f008 fc41 bl 272b6 <assert_print>
1ea34: 4040 eors r0, r0
1ea36: f380 8811 msr BASEPRI, r0
1ea3a: f04f 0003 mov.w r0, # 3
1ea3e: df02 svc 2
}
1ea40: e7bf b.n 1e9c2 <lp_cu_send_conn_param_req.isra.0+0x16>
1ea42: bf00 nop
1ea44: 2000339c .word 0x2000339c
1ea48: 00036b5d .word 0x00036b5d
1ea4c: 000334bc .word 0x000334bc
1ea50: 00031d3d .word 0x00031d3d

0001ea54 <rp_cu_complete>:
#endif /* CONFIG_BT_CTLR_CONN_PARAM_REQ */

Environment (please complete the following information):

  • OS: Windows
  • Toolchain: Zephyr SDK
  • Commit SHA: 489e8eb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Bluetooth Controller area: Bluetooth LLCP area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants