Possible Weakness with locking in the GNRC network stack #5656

In the IPv6/6loWPAN stack there are sometimes statements like this: (e.g.: sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c:95ff)

        mutex_unlock(&entry->mutex);    /* function below relocks mutex */
        gnrc_ndp_internal_send_nbr_sol(entry->pid, &tmp_addr->addr, router, router);
        mutex_lock(&entry->mutex);      /* relock mutex */

Releasing the lock and relocking it again later however breaks the atomicity of those functions, because the memory which is protected by the lock might change while the lock is not held.

I propose two possible solutions:

1. implement local function for _send_nbr_sol which do not try to lock the mutex
2. add a reentrant mutex implementation