l2cap_data_pull hard fault on disconnect with queued tx data

When using l2cap to stream data at a high rate from device to an app we are seeing a hard fault in l2cap_data_pull when there is queued l2cap send data.

When the fault occurs l2cap_data_pull, conn is in the disconnected state.  It appears that the pdu->data pointer is 0.  Then net_buf_push tries to adjust pdu->data which results in 0xfffffffc.  Dereferencing that causes the hard fault:
hdr = net_buf_push(pdu, sizeof(*hdr));
hdr->len = sys_cpu_to_le16(pdu_len);
Using nRF Connect SDK 2.9.0 and nRF5340.
Should there be a check for conn status disconnected?  Or for pdu->data == NULL?  Or is this a race condition?
Parents
  • Hi, 

    The race condition could be in the your applications, please check if you already do something like in the linked code snippet to avoid calling APIs with the conn pointer while you unref the conn pointer on disconnected: 

    https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs1/samples/bluetooth/central_gatt_write/src/central_gatt_write.c#L104-L116

    Regards,
    Amanda H.

  • The  bt_l2cap_chan_send function that we use checks the channel connection state. Is that not adequate?

  • Hi, 

    It might be a race condition between l2cap_data_pull and bt_l2cap_chan_del or l2cap_chan_shutdown. It should not happen since l2cap_data_pull runs on the system work queue, which is forced to be non-preemptible by the Bluetooth subsystem Kconfig. Have you overridden this restriction and made the system work queue preemtible?

  • We have not modified the SYSTEM_WORKQUEUE_PRIORITY configuration.

  • Could you try to surround bt_l2cap_dyn_chan_send in a k_sched_lock as a step toward debugging? This makes the thread temporarily cooperative. It can be done by applying the attached diff to NCS v2.9.0. 

    Please let me know if it can work or not.  

  • I added that change and was still able to reproduce the issue.

  • Could you provide a simple project to help us reproduce the issue?

Reply Children
No Data