Re: Kernel panic in ieee80211_chan2mode <- SIOCS80211 ioctl

From: Marcin Cieslak <saper_at_saper.info>
Date: Wed, 09 Sep 2026 21:23:53 UTC
On Wed, 9 Sep 2026, Bjoern A. Zeeb wrote:

>>>>> Can you also print se_chan details here?

(will follow up on your reply)

In the meantime I have managed to locate the ieee80211_scan_entry structure in my core
dump (it was friendly optimized away).

it looks like this:

(kgdb) p *(struct ieee80211_scan_entry *)0xfffff8023c5f9780
$99 = {se_macaddr = "\324\001Í", <incomplete sequence \323>, se_bssid = "\324\001Í", <incomplete sequence \323>,
   se_ssid = "\000\nlower-deck", '\000' <repeats 21 times>, se_rates = "\001\036\000\020\000\000\025f1\006\000\000D401C",
   se_xrates = "3\000D68D3\000\000\000\000\000\000\000\000\000", se_tstamp = {data = "\000\000\000\000\000\000\000", tsf = 0}, se_intval = 100,
   se_capinfo = 1057, se_chan = 0xfffffe00fdbcda40, se_timoff = 0, se_fhdwell = 0, se_fhindex = 0 '\000', se_dtimperiod = 0 '\000', se_erp = 0,
   se_rssi = 22 '\026', se_noise = -22 '\352', se_cc = "\000", se_meshid = '\000' <repeats 33 times>, se_ies = {wpa_ie = 0x0, rsn_ie = 0x0,
     wme_ie = 0xfffff80035d13a26 "\335\030", ath_ie = 0x0, htcap_ie = 0x0, htinfo_ie = 0x0, tdma_ie = 0x0, meshid_ie = 0x0, vhtcap_ie = 0x0,
     vhtopmode_ie = 0x0, vhtpwrenv_ie = 0x0, apchanrep_ie = 0x0, bssload_ie = 0x0, spare = {0x0, 0x0, 0x0, 0x0}, data = 0xfffff80035d13a00 "", len = 126},
   se_age = 1977}
(kgdb) p ((struct ieee80211_scan_entry *)0xfffff8023c5f9780).se_rates
$100 = "\001\036\000\020\000\000\025f1\006\000\000D401C"
(kgdb) p ((struct ieee80211_scan_entry *)0xfffff8023c5f9780).se_xrates
$101 = "3\000D68D3\000\000\000\000\000\000\000\000\000"
(kgdb) p ((struct ieee80211_scan_entry *)0xfffff8023c5f9780).se_rates[1]
$102 = 30 '\036'
(kgdb) p ((struct ieee80211_scan_entry *)0xfffff8023c5f9780).se_xrates[1]
$103 = 0 '\000'
(kgdb) x/32x 0xfffffe015d9c22a0                                 # v-- ni_rates[0]
0xfffffe015d9c22a0:     0x00    0x00    0x00    0x00    0x00    0x0f    0x00    0x10
0xfffffe015d9c22a8:     0x00    0x00    0x15    0x66    0x31    0x06    0x00    0x00
0xfffffe015d9c22b0:     0x44    0x34    0x30    0x31    0x43    0x33    0x00    0x44
0xfffffe015d9c22b8:     0x36    0x38    0x44    0x33    0x00    0x00    0x00    0x00
(kgdb) x/17x ((struct ieee80211_scan_entry *)0xfffff8023c5f9780).se_rates
0xfffff8023c5f97ae:     0x01    0x1e    0x00    0x10    0x00    0x00    0x15    0x66
0xfffff8023c5f97b6:     0x31    0x06    0x00    0x00    0x44    0x34    0x30    0x31
0xfffff8023c5f97be:     0x43

So the immediate source of a crash seems to be that ieee80211_setup_rates()
does not check if the length given by rates[1] fits the 15-byte buffer...
and happily overwrites 0x36 bytes instead.

I try to wrap my head around the ieee80211_scan_entry and ieee80211_scanparams
structures, I really feel sorry for you havubg to work on 802.11. Are those structures
prescribed by the standard? They look crazy.

The real problem is why the scan entry looks like this (MAC addresses and the SSID
are ok).

Here's se_chan:

(kgdb) p *((struct ieee80211_scan_entry *)0xfffff8023c5f9780).se_chan
$105 = {ic_flags = 1152, ic_freq = 2447, ic_ieee = 8 '\b', ic_maxregpower = 0 '\000', ic_maxpower = 0 '\000', ic_minpower = 0 '\000', ic_state = 0 '\000',
   ic_extieee = 0 '\000', ic_maxantgain = 0 '\000', ic_pad = 0 '\000', ic_devdata = 0, ic_vht_ch_freq1 = 0 '\000', ic_vht_ch_freq2 = 0 '\000', ic_freq2 = 0}