RRM beacon report stack buffer overflow
   CWE-121.  CVSS 3.1: 8.8 High
   CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
   src/rrm.c:334 and :370, rrm_report_beacon_results()
   Introduced 1.1, commit 1f01819c701e

   rrm_report_beacon_results() builds a Radio Measurement Report action
   frame in uint8_t frame[512] on the stack.  The loop appends one 31-byte
   record per matching BSS - a 5-byte Measurement Report IE header plus a
   26-byte packed rrm_beacon_report - and advances the write pointer with
   "ptr += report_len + 5" and no bounds check.  After the 3-byte action
   header, 16 records fit.  Record 17 writes frame[499..529].  The BSS list
   is the station's own scan cache, so the count is a property of the RF
   environment - but an attacker can deterministically reach the threshold
   by transmitting additional fake beacons.

   rrm_frame_watch_cb() requires STATION_STATE_CONNECTED (rrm.c:727), then
   does a bare memcmp of the frame's address_2 against the connected AP's
   MAC (rrm.c:733).  There is no PMF requirement, so on WPA2 without
   802.11w that source address is whatever the attacker puts in it.  One
   request clears all three per-BSS filters: a wildcard BSSID
   (ff:ff:ff:ff:ff:ff) skips the BSSID compare, omitting the SSID
   sub-element skips the SSID compare, and mode=TABLE permits channel=0,
   which makes bss_in_request_range() return true unconditionally.  Every
   cached BSS is then reported.

   Request fields and attacker-generated beacon metadata make parts of each
   overflowing record attacker-controlled.

   Outcomes are build-dependent:
     * Hardened distro builds abort in __stack_chk_fail.
     * In the tested no-canary x86-64 build, the zeroed scan_start_time
       field overwrote saved RIP, producing a crash without control.
     * In a representative unhardened ARM32 layout, the saved lr is
       reachable and holds attacker bytes.  I demonstrated pc hijack on
       armhf in a harness reproducing that frame layout (exit code 42 from
       win()).  That shows the primitive reaches the return address on the
       ABI; it is not an exploit against a shipped binary, since the record
       and field that land on lr depend on the build's register allocation.

   FORTIFY_SOURCE does not help.  Each individual memcpy is in bounds; the
   overflow comes from the loop accumulating them.

   Evidence - AddressSanitizer on a real iwd 3.12 daemon, driven over
   mac80211_hwsim with 21 cached BSSes and the action frame sent via
   NL80211_CMD_FRAME:

     ==67193==ERROR: AddressSanitizer: stack-buffer-overflow
     WRITE of size 26 at 0x7ffe8136a2a0 thread T0
         #3 in rrm_report_beacon_results src/rrm.c:367
       [384, 896) 'frame' (line 334) <== Memory access at offset 896
                                         overflows this variable