Skip to content

Possible Weakness with locking in the GNRC network stack #5656

@melshuber

Description

@melshuber

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

Metadata

Metadata

Labels

Area: networkArea: NetworkingType: bugThe issue reports a bug / The PR fixes a bug (including spelling errors)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions