linux-kernel - Re: [PATCH wireless-next] wifi: mac80211: reject VHT opmode for unsupported channel widths

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF3JpA7ZeG5uxLJr1NQBBzF=UZRi4sj4TSfBw=Pvx7xb1NCqTw@mail.gmail.com>
Date: Thu, 3 Jul 2025 09:35:22 -0700
From: Moonhee Lee <moonhee.lee.ca@...il.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: Nicolas Escande <nico.escande@...il.com>, linux-wireless@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-kernel-mentees@...ts.linux.dev, 
	syzbot+ededba317ddeca8b3f08@...kaller.appspotmail.com
Subject: Re: [PATCH wireless-next] wifi: mac80211: reject VHT opmode for
 unsupported channel widths

Hi Johannes,

On Thu, Jul 3, 2025 at 8:09 AM Johannes Berg <johannes@...solutions.net> wrote:
>
> I'm not entirely sure that'd be correct. 320 MHz can only be used on the
> 6 GHz band, so clients must be at least HE, but I'm not sure that VHT
> opmode notification frames are completely illegal for them, even if
> they'd like use OMI instead.
>

Understood. That clarifies the case for not filtering out 320 MHz, even when a
VHT opmode notification is present.

On Thu, Jul 3, 2025 at 8:11 AM Johannes Berg <johannes@...solutions.net> wrote:
>
> n/m, it just did that quite explicitly. I really want to get rid of all
> that 5/10 MHz code, but we still have S1G so that might still happen
> anyway, and I expect for S1G VHT operating mode notification frames
> _are_ invalid.

To address this, I plan to reject the set of channel widths that are not valid
with VHT opmode. This includes all channel widths below 20 MHz, as well as
20 MHz without HT (20_NOHT), which is also incompatible.

Would the following logic for v2 be acceptable?

    /* reject channel widths not valid with VHT opmode */
    switch (width) {
    case NL80211_CHAN_WIDTH_5:
    case NL80211_CHAN_WIDTH_10:
    case NL80211_CHAN_WIDTH_1:
    case NL80211_CHAN_WIDTH_2:
    case NL80211_CHAN_WIDTH_4:
    case NL80211_CHAN_WIDTH_8:
    case NL80211_CHAN_WIDTH_16:
    case NL80211_CHAN_WIDTH_20_NOHT:
        return -EINVAL;
    default:
        break;
    }

This allows valid HT/VHT channel widths, including 20, 40, 80, 80+80, 160, and
320, to pass through while filtering out values that would otherwise trigger a
WARN_ON.

Best regards,
Moonhee