On Tue, 2025-08-26 at 18:54 +1000, Lachlan Hodges wrote: > Currently the S1G capability element is not taken into account > for the scan_ies_len, which leads to a buffer length validation > failure in ieee80211_prep_hw_scan() and subsequent WARN in > __ieee80211_start_scan(). This prevents hw scanning from functioning. > To fix ensure we accommodate for the S1G capability length. > > Signed-off-by: Lachlan Hodges <lachlan.hodges@xxxxxxxxxxxxxx> > --- > v2 -> v3: don't include kernel test robot for a new patch... > > Again, targetted wireless.. but not really sure if this qualifies > as a "bug"... I gave my reasoning in the reply to the first patch: > > https://lore.kernel.org/linux-wireless/3j7kkqznavkxt23iopacl626xkppzcitiactxz43axqorucrvu@6gaixffy7zaj/ I'm happy with it to go to wireless, and will just do that at this stage, but I'm also curious how it would matter at all there? The only driver with S1G right now is hwsim, I believe, which always has also other bands and HT/VHT/etc., so wouldn't it allocate more than enough space anyway? Feels like you should only be able to run into this with a driver that only has S1G, and no such driver exists upstream? Or am I confused? johannes
