mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-13 07:31:07 +00:00
wifi: mac80211: Fix a race when expiring a mesh path
My static analyzer identified a potential issue in 'net/mac80211/mesh_pathtbl.c':
mpath_expired() reads mpath->flags and mpath->exp_time without holding
mpath->state_lock, while mesh_path_fix_nexthop() and the other writers update
both fields under that lock. In mpath_lookup() and
__mesh_path_lookup_by_idx() the unlocked check is followed by taking the lock
and clearing MESH_PATH_ACTIVE, so the check and the update are not atomic:
CPU0 (mpath_lookup) CPU1 (mesh_path_fix_nexthop)
mpath_expired() reads the stale
flags/exp_time and returns true
spin_lock_bh(&mpath->state_lock)
mpath->exp_time = 0;
mpath->flags = FIXED|SN_VALID;
mesh_path_activate(mpath);
spin_unlock_bh(&mpath->state_lock)
spin_lock_bh(&mpath->state_lock)
mpath->flags &= ~MESH_PATH_ACTIVE;
spin_unlock_bh(&mpath->state_lock)
A path which mesh_path_fix_nexthop() has just set up as MESH_PATH_FIXED and
MESH_PATH_ACTIVE then has MESH_PATH_ACTIVE cleared again, and forwarding to
that destination silently stops.
Take mpath->state_lock before evaluating mpath_expired() so that the check and
the clearing of MESH_PATH_ACTIVE are atomic with respect to the writers.
Fixes: 60854fd945 ("mac80211: mesh: convert path table to rhashtable")
Signed-off-by: Ginger Li <ginger.jzllee@gmail.com>
Link: https://patch.msgid.link/20260922054253.11976-1-ginger.jzllee@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This commit is contained in:
parent
12bc27e79a
commit
6571b6a24c
1 changed files with 7 additions and 6 deletions
Loading…
Add table
Add a link
Reference in a new issue