https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269898
Bug ID: 269898
Summary: broadcast addr4/meshSA causes NULL deref or panic in
ieee80211_mesh.c
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: wireless
Assignee: wireless@FreeBSD.org
Reporter: r...@lcs.mit.edu
Attachment #240508 text/plain
mime type:
Created attachment 240508
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240508&action=edit
send an 802.11 mesh packet that causes a panic: no route in
mesh_recv_indiv_data_to_fwrd()
If an 802.11 mesh data packet to be forwarded has addr4/meshSA set to
ff:ff:ff:ff:ff:ff, an INVARIANTS kernel will panic in
mesh_recv_indiv_data_to_fwrd():
/* set lifetime of addr4 (meshSA) to initial value */
rt_meshsa = ieee80211_mesh_rt_find(vap, qwh->i_addr4);
KASSERT(rt_meshsa != NULL, ("no route"));
The corresponding KASSERT in mesh_recv_indiv_data_to_me() can also be
triggered by an incoming packet. These turn into NULL dereferences in
non-INVARIANTS kernels.
I've attached a demo, which depends on the wtap kernel module
and the wtap and vis_map utilities:
# cc wtap30b.c
# ./a.out
panic: no route
panic() at panic+0x2a
mesh_recv_indiv_data_to_fwrd() at mesh_recv_indiv_data_to_fwrd+0x146
mesh_input() at mesh_input+0x6d4
.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
--
You are receiving this mail because:
You are the assignee for the bug.
