Created attachment 239919 [details] produce a panic with a bad PREQ 802.11 mesh action frame If an 802.11 mesh peer sends a PREQ action frame with broadcast preq_orgaddr, hwmp_recv_preq() will call ieee80211_mesh_rt_add() with that address, and mesh_rt_add_locked() will panic. Similar problems exist with calls to ieee80211_mesh_rt_add() for PREP and RANN frames. I've attached a demo: # cc wtap19a.c # ./a.out wlan0: received action from 00:98:9a:98:96:98 rssi 128 wlan0: [00:98:9a:98:96:98] received PREQ, orig ff:ff:ff:ff:ff:ff, targ(0) ff:ff:ff:ff:ff:ff panic: mesh_rt_add_locked: adding broadcast to the routing table panic() at panic+0x2a mesh_rt_add_locked() at mesh_rt_add_locked+0x11a ieee80211_mesh_rt_add() at ieee80211_mesh_rt_add+0x60 hwmp_recv_preq() at hwmp_recv_preq+0xac4 hwmp_recv_action_meshpath() at hwmp_recv_action_meshpath+0x29a ieee80211_recv_action() at ieee80211_recv_action+0x13c mesh_recv_mgmt() at mesh_recv_mgmt+0x202 wtap_recv_mgmt() at wtap_recv_mgmt+0x28 mesh_input() at mesh_input+0x512 .LBB2_17() at .LBB2_17+0x34 taskqueue_run_locked() at taskqueue_run_locked+0x96 taskqueue_thread_loop() at taskqueue_thread_loop+0x62 fork_exit() at fork_exit+0x80 fork_trampoline() at fork_trampoline+0xa
(In reply to Robert Morris from comment #0) There are lots of calls to ieee80211_mesh_rt_add() that probably ought to be guarded by checks for broadcast, for example from mesh_checkpseq().