REDHAT-BUG-2560194: Buffer Overflow

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, rrmreportbeaconresults() Introduced 1.1, commit 1f01819c701e

rrmreportbeaconresults() builds a Radio Measurement Report action frame in uint8t 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 rrmbeaconreport - and advances the write pointer with "ptr += reportlen + 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.

rrmframewatchcb() requires STATIONSTATECONNECTED (rrm.c:727), then does a bare memcmp of the frame's address2 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 bssinrequestrange() 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 stackchkfail. In the tested no-canary x86-64 build, the zeroed scanstarttime 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.

FORTIFYSOURCE 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 mac80211hwsim with 21 cached BSSes and the action frame sent via NL80211CMDFRAME:

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