Bug #443
closedtvlv: concurrent flags modification
0%
Description
could there be a race condition when modifying tvlv_handler->flags concurrently? Later in this function, we loop through handlers and modify the shared flags without synchronization:
if ((tvlv_handler->flags & BATADV_TVLV_HANDLER_OGM_CIFNOTFND) &&
!(tvlv_handler->flags & BATADV_TVLV_HANDLER_OGM_CALLED))
tvlv_handler->ogm_handler(bat_priv, orig_node,
cifnotfound, NULL, 0);
tvlv_handler->flags &= ~BATADV_TVLV_HANDLER_OGM_CALLED;
Because tvlv_handler comes from the global bat_priv->tvlv.handler_list and OGM packets can be processed concurrently via batadv_batman_skb_recv() in softirq context, could CPU1 clear BATADV_TVLV_HANDLER_OGM_CALLED just as CPU2 sets it via batadv_tvlv_call_handler()? If CPU2 observes the flag as cleared, wouldn't it erroneously conclude that the originator failed to include the expected TVLV data, causing incorrect drops of DAT or Multicast capabilities for an originator?
See https://sashiko.dev/#/patchset/20260614-tvlv-2b-align-v1-1-6e21383cd287%40narfation.org
Updated by Sven Eckelmann 4 months ago
- Status changed from New to In Progress
- Target version set to 2026.2
Proposed patches: https://patchwork.open-mesh.org/project/b.a.t.m.a.n./list/?series=767
Updated by Sven Eckelmann 4 months ago
- Status changed from In Progress to Resolved