[nrf fromlist] Bluetooth: ATT: lock scheduler when sending from user …

…thread

`att_req_send_process` is not thread safe.

In the case where the current context is pre-emptible (e.g. when a user
sends something over GATT from the main thread):

The iterator in `att_req_send_process` can get interrupted mid-processing,
breaking the logic and resulting in an assert/crash/data corruption.

Additionally, the connection state check in this fn is also not
thread-safe, the RX thread could pre-empt us and disconnect right before
we attempt to send on an ATT bearer that is on it.

This is a hotfix until we have a generalized solution for the host API
surface. It seems a lot of our logic assumes cooperative priority.

Upstream PR: zephyrproject-rtos/zephyr#69738

Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>

subsys/bluetooth/host/att.c

@@ -3928,14 +3928,19 @@ int bt_att_req_send(struct bt_conn *conn, struct bt_att_req *req)
 	__ASSERT_NO_MSG(conn);
 	__ASSERT_NO_MSG(req);
 
+	k_sched_lock();
+
 	att = att_get(conn);
 	if (!att) {
+		k_sched_unlock();
 		return -ENOTCONN;
 	}
 
 	sys_slist_append(&att->reqs, &req->node);
 	att_req_send_process(att);
 
+	k_sched_unlock();
+
 	return 0;
 }