All of lore.kernel.org
 help / color / mirror / Atom feed
From: Slawomir Stepien <sst@poczta.fm>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: syzkaller-bugs@googlegroups.com, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org, syzbot@lists.linux.dev,
	syzbot+9bdc0c5998ab45b05030@syzkaller.appspotmail.com
Subject: Re: [PATCH v2] mac80211: reject station addition if AP or MLO link is inactive
Date: Mon, 3 Aug 2026 15:09:56 +0200	[thread overview]
Message-ID: <anCTJFZ54Y93O8Qs@nr200> (raw)
In-Reply-To: <28f4f5b6fbe594c41538d5068b2d77495250ecd7.camel@sipsolutions.net>

On lip 31, 2026 14:40, Johannes Berg wrote:
> On Mon, 2026-07-27 at 15:26 +0200, Slawomir Stepien wrote:
> > After taking a closer look at this I wonder how AP_VLAN should be handled? Is there a way on
> > cfg80211 level to be able to check AP_VLAN's main device state?
> 
> Hmm, yeah that might be an issue? I guess in theory it could track it,
> but it doesn't.
> 
> > My code change would look something like this:
> > 
> > @@ -9404,6 +9404,12 @@ static int nl80211_new_station(struct sk_buff *skb, struct genl_info *info)
> >         case NL80211_IFTYPE_AP:
> >         case NL80211_IFTYPE_AP_VLAN:
> >         case NL80211_IFTYPE_P2P_GO:
> > +               /* Add new station only after the AP and link has been started */
> > +               int link = params.link_sta_params.link_id >= 0 ?
> > +                          params.link_sta_params.link_id : 0;
> > +               if (!wdev->links[link].ap.beacon_interval)
> > +                       return -ENETDOWN;
> > +
> >                 /* ignore WME attributes if iface/sta is not capable */
> >                 if (!(rdev->wiphy.flags & WIPHY_FLAG_AP_UAPSD) ||
> >                     !(params.sta_flags_set & BIT(NL80211_STA_FLAG_WME)))
> > 
> > but the NL80211_IFTYPE_AP_VLAN case would not work here, right? Can I just do the checking only for
> > NL80211_IFTYPE_AP and NL80211_IFTYPE_P2P_GO and skip NL80211_IFTYPE_AP_VLAN?
> 
> Yeah it'd just reject everything, I guess.
> 
> I think in practice stations are added at the AP interface first and
> then moved to a VLAN, which would argue for actually rejecting

But are they moved and then this `case NL80211_IFTYPE_AP_VLAN` should match?
In my tests this case doesn't match, even after the STA is assoc with vlan interface (e.g.
wlan0.10).

My test is done using qemu with:

Files:
------
==> hostapd.accept <==
02:00:00:00:01:00 10

==> hostapd.conf <==
interface=wlan0
driver=nl80211
ssid=VLAN_Test_AP
hw_mode=g
channel=1

# Basic WPA2-PSK
wpa=2
wpa_passphrase=password123
wpa_key_mgmt=WPA-PSK

# Enable MAC-based Access Control and VLAN Assignment
macaddr_acl=1
accept_mac_file=/root/hostapd.accept

# Enable Dynamic VLAN interface creation
dynamic_vlan=1
vlan_file=/root/hostapd.vlan
vlan_naming=1

==> hostapd.vlan <==
10  wlan0.10  br10

==> wpa.conf <==
p2p_disabled=1
network={
        ssid="VLAN_Test_AP"
        #psk="password123"
        psk=c31c83ea62af5b750232dc32865586f7658777dce974a980446dd6bff0154913
}

Commands:
---------
modprobe mac80211_hwsim radios=2
ip link add br10 type bridge
ip link set br10 up
hostapd -d hostapd.conf -B
wpa_supplicant -i wlan1 -c wpa.conf

Results:
--------
# iw dev
phy#1
        Interface wlan1
                ifindex 5
                wdev 0x100000001
                addr 02:00:00:00:01:00
                type managed
                channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
                txpower 20.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0
phy#0
        Interface wlan0.10
                ifindex 8
                wdev 0x2
                addr 02:00:00:00:00:00
                type AP/VLAN
                channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
                txpower 20.00 dBm
        Interface wlan0
                ifindex 4
                wdev 0x1
                addr 02:00:00:00:00:00
                ssid VLAN_Test_AP
                type AP
                channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
                txpower 20.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       33      0       0       0       0       3868            33

# iw dev wlan0.10 station dump
Station 02:00:00:00:01:00 (on wlan0.10)
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        no
        MFP:            no
        TDLS peer:      no
        inactive time:  5676 ms
        rx bytes:       3569
        rx packets:     30
        tx bytes:       410
        tx packets:     4
        tx retries:     0
        tx failed:      0
        rx drop misc:   0
        signal:         -30 dBm
        signal avg:     -30 dBm
        tx bitrate:     1.0 MBit/s
        tx duration:    0 us
        rx bitrate:     54.0 MBit/s
        rx duration:    0 us
        DTIM period:    0
        beacon interval:0
        connected time: 238 seconds
        associated at [boottime]:       30.496s
        associated at:  1785761454053 ms
        current time:   1785761692411 ms

# dmesg | grep laza
(this is just a print of this field just before the switch() call)
[   30.489902][  T189] laza: info->attrs[NL80211_ATTR_IFINDEX]: 4
(and yes, it is just one print triggered)

This index 4 is assigned to wlan0, so it will never have iftype == NL80211_IFTYPE_AP_VLAN.
Also the print of wdev->identifier will give 0x1 and not 0x2.

So, is it even possible that `case NL80211_IFTYPE_AP_VLAN` would match? If it will never match, then
do I understand that the change I proposed should be correct for other cases?

> everything being OK anyway - but then that shouldn't be because of this
> but rather by just removing the AP_VLAN case there, or so.
> 
> Not sure what the best thing would be though.

-- 
Slawomir Stepien

  reply	other threads:[~2026-08-03 13:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27  7:45 [PATCH v2] mac80211: reject station addition if AP or MLO link is inactive Slawomir Stepien
2026-07-27  8:19 ` Johannes Berg
2026-07-27  9:22   ` Slawomir Stepien
2026-07-27  9:25     ` Johannes Berg
2026-07-27 10:26       ` Slawomir Stepien
2026-07-27 13:26         ` Slawomir Stepien
2026-07-31 12:40           ` Johannes Berg
2026-08-03 13:09             ` Slawomir Stepien [this message]
2026-08-03 13:15               ` Johannes Berg
2026-07-27 13:44 ` [syzbot ci] " syzbot ci

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anCTJFZ54Y93O8Qs@nr200 \
    --to=sst@poczta.fm \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=syzbot+9bdc0c5998ab45b05030@syzkaller.appspotmail.com \
    --cc=syzbot@lists.linux.dev \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.