Re: Kernel panic in ieee80211_chan2mode <- SIOCS80211 ioctl

On Wed, 9 Sep 2026, Marcin Cieslak wrote:

> 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:
>
..
> 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.

ASSOC/REASSOC_RESP do check:
    1833                 rate = ieee80211_setup_rates(ni, rates, xrates,

but that's not our case.

ieee80211_sta_join() and ieee80211_init_neighbor() take them from the scan_parm or
scan_results w/o further checks.

ieee80211_sta_join() in our case get's it from the lookup code in the ioctl
I mentioned previously.

So the question is, does ieee80211_add_scan() and follow-up code check?

ieee80211_swscan_add_scan() does not.
sta_add() has a KASSERT:

     278         KASSERT(sp->rates[1] <= IEEE80211_RATE_MAXSIZE,
     279                 ("rate set too large: %u", sp->rates[1]));

Now the question is:  what's your VAIO kernel?  GENERIC or NODEBUG?

In either way, this is suboptimal but also now I need to go back and look
at the input again and where it comes from.

It seems brcmf_parse_ies() doesn't check that anything fits or is valid beyond
the point that IEs fit into the frame?

That leads me to the question: what does your AP send you?
Can you capture a beacon frame (on a different machine)?

Speaking of that, what machine did you say do you have with a brmcfmac in it?


> 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.

They make sense and not so much anymore.

The reason I replied to the AI driver was that I was seeing the chance of net80211
improvements (even if the real problem may sit elsehwere).  And net80211 tech debt
is on my agenda.


> 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}

That looks valid still, which is likely due to
sys/net80211/ieee80211_scan_sta.c::sta_add() doing:

     328                 ise->se_chan = curchan;


-- 
For there shall arise false Christs, and false prophets, and shall shew
great signs and wonders; insomuch that, if it were possible, they shall
deceive the very elect. Behold, I have told you before. [Mat. 24:24-25]