On Tue, Aug 26, 2025 at 01:49:51PM +0200, Johannes Berg wrote: > 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? Thanks Johannes, and no you are not confused. In retrospect I should've just targeted wireless-next since the "bug" didn't affect anything upstream anyway (since hwsim used the other lengths as mentioned). lachlan
