l2cap_data_pull hard fault on disconnect with queued tx data

[denis]

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?

[denis]

I also added a check that struct bt_l2cap_le_chan chan_ops disconnected has not been called before we call bt_l2cap_chan_send.

So I think the send data is queued up the ble stack before the disconnect happens.

[denis]

Just to check to see if bt_conn_unref was the issue, I commented that out to test.  The same hard fault in l2cap_data_pull occurs.  So doesn't seem to be an issue with an early unref.

[Amanda Hsieh]

Could you try the suggested code snippet?

[denis]

I can't do that exactly because I'm using the l2cap calls, but I did test adding a ref/unref around the send and the same hard fault still happens.

struct bt_conn *conn = bt_conn_ref(conn_connected);

int result = bt_l2cap_chan_send(&pt_ble.l2cap.le_chan.chan, buf);

bt_conn_unref(conn);

[Amanda Hsieh]

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?