Skip site navigation (1)Skip section navigation (2) 
Date:      Sun, 05 Feb 2023 18:22:18 +0000
From:      bugzilla-noreply@freebsd.org
To:        wireless@FreeBSD.org
Subject:   [Bug 269343] bad 802.11 mesh PREQ packet can generate panic: null node from hwmp_send_action()
Message-ID:  <bug-269343-21060@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269343

            Bug ID: 269343
           Summary: bad 802.11 mesh PREQ packet can generate panic: null
                    node from hwmp_send_action()
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: wireless
          Assignee: wireless@FreeBSD.org
          Reporter: rtm@lcs.mit.edu
 Attachment #239923 text/plain
         mime type:

Created attachment 239923
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D239923&action=
=3Dedit
generate an 802.11 mesh action PREQ frame that causes panic: null node

I don't understand the scenario, but the attached demo program
generates an 802.11 mesh PREQ action packet that triggers this panic
in hwmp_send_action():

        // da is 00:00:00:00:00:00

        if (IEEE80211_IS_MULTICAST(da)) {
          // not this
        }
        else {
                ni =3D ieee80211_mesh_find_txnode(vap, da);
                // now ni =3D=3D NULL
        }
        ...;
        KASSERT(ni !=3D NULL, ("null node"));

The call from hwmp_recv_preq() to hwmp_send_prep() is the one on line
1177 of ieee80211_hwmp.c; rtorig->rt_nexthop is 00:00:00:00:00:00.

        /*
         * Proactive PREQ: reply with a proactive PREP to the
         * root STA if requested.
         */
        if (IEEE80211_ADDR_EQ(PREQ_TADDR(0), broadcastaddr) &&
            (PREQ_TFLAGS(0) & IEEE80211_MESHPREQ_TFLAGS_TO)) {
                ...;
                /*
                 * Reply with a PREP if we don't have a path to the root
                 * or if the root sent us a proactive PREQ.
                 */
                if ((rtorig->rt_flags & IEEE80211_MESHRT_FLAGS_VALID) =3D=
=3D 0 ||
                    (preq->preq_flags & IEEE80211_MESHPREQ_FLAGS_PP)) {
                        ...;
                        hwmp_send_prep(vap, rtorig->rt_nexthop, &prep);

The demo:

# cc wtap19c.c
# ./a.out
...
wlan0: [00:98:9a:98:96:98] received PREQ, orig ff:ff:7f:ff:ff:ff, targ(0)
ff:ff:ff:ff:ff:ff
wlan0: [00:98:9a:98:96:98] adding originator ff:ff:7f:ff:ff:ff
wlan0: [00:98:9a:98:96:98] root mesh station @ ff:ff:7f:ff:ff:ff
wlan0: [ff:ff:7f:ff:ff:ff] stored new gate information from pro-PREQ.
panic: null node
panic() at panic+0x2a
hwmp_send_action() at hwmp_send_action+0x2e0
hwmp_send_prep() at hwmp_send_prep+0x2a
hwmp_recv_preq() at hwmp_recv_preq+0x76e
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

--=20
You are receiving this mail because:
You are the assignee for the bug.=

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-269343-21060>