wifi: esp_at: race condition on mutex's leading to deadlock

[JordanYates]

Describe the bug

The send and receive code paths for Zephyr sockets when using the ESP AT command WiFi driver claim the same two mutex's in different orders. This leads to a permanent deadlock when you get unlucky with packet timings.

When receiving

The ESP RX thread claims the socket mutex before calling into the Zephyr socket library.

zephyr/drivers/wifi/esp_at/esp_socket.c

Lines 172 to 174 in c32d10c

	k_mutex_lock(&sock->lock, K_FOREVER);
	if (sock->recv_cb) {
	sock->recv_cb(sock->context, pkt, NULL, NULL,

zsock_received_cb then claims the net_context mutex.

zephyr/subsys/net/lib/sockets/sockets.c

Lines 361 to 369 in c32d10c

	static void zsock_received_cb(struct net_context *ctx,
	struct net_pkt *pkt,
	union net_ip_header *ip_hdr,
	union net_proto_header *proto_hdr,
	int status,
	void *user_data)
	{
	if (ctx->cond.lock) {
	(void)k_mutex_lock(ctx->cond.lock, K_FOREVER);

When transmitting

zsock_send_message claims the net_context mutex (inside net_context_sendmsg).

zephyr/subsys/net/ip/net_context.c

Lines 1788 to 1799 in c32d10c

	int net_context_sendmsg(struct net_context *context,
	const struct msghdr *msghdr,
	int flags,
	net_context_send_cb_t cb,
	k_timeout_t timeout,
	void *user_data)
	{
	int ret;
	k_mutex_lock(&context->lock, K_FOREVER);
	ret = context_sendto(context, msghdr, 0, NULL, 0,

esp_socket_queue_tx then claims the socket mutex.

zephyr/drivers/wifi/esp_at/esp.h

Lines 364 to 369 in c32d10c

	static inline int esp_socket_queue_tx(struct esp_socket *sock,
	struct net_pkt *pkt)
	{
	int ret = -EBUSY;
	k_mutex_lock(&sock->lock, K_FOREVER);

Expected behavior
Mutex's should be claimed in the same order in all code paths to avoid deadlock.

Impact
WiFi driver is permanently unusable until the application is power cycled.

Environment (please complete the following information):

• Zephyr v2.7.1
• Zephyr v3.0.0