summaryrefslogtreecommitdiff
path: root/net/mac80211/tx.c
AgeCommit message (Collapse)Author
2026-10-13wifi: mac80211: reserve MME tailroom for protected beaconsChien Wong
Beacon protection appends an MME to beacons, but the skb allocation does not reserve tailroom for it. If the available tailroom is too small, the crypto path drops the beacon. Two factors often mask this: the 256-byte TIM reservation is rarely fully used, and dev_alloc_skb() may round up the allocation, leaving extra tailroom. Neither guarantees enough room for the MME. Reserve enough room for the largest MME. Fixes: 0a3a84360b37 ("mac80211: Beacon protection using the new BIGTK (AP)") Signed-off-by: Chien Wong <m@xv97.com> Link: https://patch.msgid.link/20261012140738.70178-3-m@xv97.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-10-13wifi: mac80211: don't require wiphy mutex for control port TXJohannes Berg
The wiphy mutex was only required for the cookie counter, but that's been in cfg80211 for a while. The rest is just datapath, so can work under RCU, just need to be careful to handle interface type changes. Link: https://patch.msgid.link/20261009201417.dffb8da303aa.Ica8bba30018704a7c776f2ef08e6f2571cd8f8c4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-10-09wifi: mac80211: use link address as TA for non-MLO 4-addr station on MLD APFelix Fietkau
A 4-address AP_VLAN always sets A2 to sdata->vif.addr, which on an MLD AP is the AP MLD address. For a non-MLO station, A2 must be the link address it associated to. Use the link address for a non-MLO station in the 4-address case as well, like the AP case already does in ieee80211_build_hdr() and ieee80211_check_fast_xmit(). Share the address selection between both cases and both TX paths. Fixes: 3e0278b717b0 ("wifi: mac80211: select link when transmitting to non-MLO stations") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20261007105249.1234601-1-nbd@nbd.name [use guard] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-10-09wifi: mac80211: fix TDLS setup frame length checkJohannes Berg
If TDLS setup packets are created by AF_PACKET or so, then the payload may not be present. Since we only care about those mac80211 generated (which are linear), just replace the skb->len check with a skb_headlen() check to avoid any out-of-bounds accesses. Assisted-by: LLM Link: https://patch.msgid.link/20261005224950.c3cf023d5191.Id537db8aca13e6df999938a3bc4cc6ce2a28f733@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-10-09wifi: mac80211: don't read runt headers in injectionJohannes Berg
For injection we only check the header is in the skb head, but e.g. ACK/CTS are really short, and we then try to use A2 anyway. Require A1 (no S1G extension frames) and use A2 only when present. Assisted-by: LLM Link: https://patch.msgid.link/20261005224950.0f3c3e88abde.I03477f2444a9f2cb2888d00320ac7c4504f150a3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-10-09wifi: mac80211: limit injected HT/VHT MCSesJohannes Berg
With radiotap injection the HT/VHT MCSes can be just about anything, but that can later get problematic. Limit them to the rates the device reports, which is presumably going to be a subset of what mac80211 can do, except for HT MCS 32 which some devices report as supported, but then TX status can't deal with it. If it's not supported just ignore the config. Assisted-by: LLM Fixes: dfdfc2beb0dd ("mac80211: Parse legacy and HT rate in injected frames") Fixes: 646e76bb5daf ("mac80211: parse VHT info in injected frames") Link: https://patch.msgid.link/20261005224950.68e210b8487a.I2ee0e4664c54cf31002eb9e4f5190fd05ff4130f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-10-09wifi: mac80211: init radiotap iter after length checksJohannes Berg
The radiotap iterator initialization will already parse the presence bitmaps, so it accesses a good part of the header. This might not be present in the linear part of the SKB, we haven't checked it at this point. Check the lengths first. Assisted-by: LLM Fixes: cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue") Link: https://patch.msgid.link/20261005224950.b5c2c31790d2.I091422db411b595bde4dba2de69334cd2aeb33b0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-10-06wifi: mac80211: use the AP address as RA for a 4-addr MLO stationFelix Fietkau
In 4-address mode, ieee80211_build_hdr() and ieee80211_check_fast_xmit() set A1 to sdata->deflink.u.mgd.bssid, which is not valid for an MLO connection. Use sdata->vif.cfg.ap_addr instead, like the 3-address case does. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260930084819.3000572-2-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-10-01Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.3-rc6). Conflicts: net/mac80211/tx.c net/mac80211/ieee80211_i.h 8effab902fa34 ("wifi: mac80211: prevent AP VLAN tx from other interfaces") 78b843974fb83 ("wifi: mac80211: report multicast transmission from lookup_ra_sta()") https://lore.kernel.org/arJmcuhpJ69wAvYK@sirena.co.uk drivers/net/ethernet/realtek/r8169_main.c 3cdeaef1754ab ("r8169: disable EEE on RTL8168h/8111h") 8a3c76523e449 ("r8169: add support for phylink") https://lore.kernel.org/ar5vAxEqS8tO8aVT@sirena.org.uk Adjacent changes: rust/kernel/net/netlink.rs 5e5916923759 ("rust: net: netlink: Migrate to zerocopy's IntoBytes") 0923198be4ae ("rust: net: netlink: validate attribute length before casting to `c_int`") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-28wifi: mac80211: fix potential ack-skb leak on error pathJohannes Berg
In case this warning hits, which shouldn't but could at least due to an unrelated mesh bug, an ack SKB will not be freed correctly if present. Fix that. Reported-by: syzbot+ac648b0525be1feba506@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260922144845.729cf61a017b.Iabf0248920a1e70c9f6f321fbf163fc10e5f0884@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-28wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()Cen Zhang (Microsoft)
ieee80211_monitor_select_queue() validates the skb length using skb->len before dereferencing pointers into skb->data to access the 802.11 header. However, skb->len includes data in both the linear head buffer and non-linear fragments/pages. When AF_PACKET sends a packet large enough to become non-linear, the 802.11 header at skb->data + len_rthdr may extend past the linear head buffer even though skb->len appears sufficient. This leads to a slab-out-of-bounds read when accessing hdr->frame_control, as the kernel reads beyond the allocated skb head buffer: BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue+0x1ed/0x220 syzbot has hit the same issues. Fix this by checking skb_headlen(skb) (which gives the length of the linear data region) instead of skb->len before dereferencing skb->data pointers. This ensures the required bytes are actually present in the linear portion of the skb. Apply the same fix to ieee80211_validate_radiotap_len() which has the same class of bug: it uses skb->len to validate accesses to skb->data, and to the corresponding checks in ieee80211_monitor_start_xmit(): for drivers advertising NETIF_F_SG the skb is not linearized before ndo_start_xmit, so the 802.11 header can be read past the linear buffer there as well. Fixes: cf0277e714a0 ("mac80211: fix skb buffering issue") Fixes: 9b8a74e3482f ("[MAC80211]: Improve sanity checks on injected packets") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: syzbot+610e40369bc02181bad0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=610e40369bc02181bad0 Reported-by: syzbot+878643e0580bc580f883@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=878643e0580bc580f883 Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Cen Zhang (Microsoft) <cenzhang@linux.microsoft.com> Reviewed-by: Francis Perron <francis@akrites.dev> Link: https://patch.msgid.link/20260925024408.32143-1-cenzhang@linux.microsoft.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-28wifi: mac80211: set info->band for 802.3 encap offload framesFelix Fietkau
Unlike the 802.11 TX paths, ieee80211_8023_xmit() does not set info->band from the channel context on non-MLD interfaces. It stays at 0, so ieee80211_get_tx_rates() uses the wrong band for these frames. Set it the same way as ieee80211_build_hdr(): drop the frame if there is no channel context, and leave the band at 0 on MLD interfaces. Reported-by: Andrea Pesaresi <andreapesaresi82@gmail.com> Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260926120216.4054712-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-22wifi: mac80211: prevent AP VLAN tx from other interfacesFelix Fietkau
Since the station lookup was factored out of ieee80211_build_hdr(), ieee80211_lookup_ra_sta() uses sta_info_get_bss() for all AP and AP VLAN frames, not only for control port frames. A unicast frame sent on one interface thus matches a station of a different VLAN of the same BSS and is transmitted to it. Only match stations of the interface the frame is sent on, except for control port frames, since those may be sent for VLAN stations directly on the BSS interface. Fixes: 97ffe75791b3 ("mac80211: factor out station lookup from ieee80211_build_hdr()") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260916094833.164219-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-21Merge tag 'wireless-next-2026-09-21' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== More changes, including drivers: - brcmfmac: FT/OKC roaming offload - ath12k: IPQ5332 platform infrastructure - cfg80211/mac80211: non-STA TX/RX infrastructure for MLO to fix address translation bugs - the rest is mostly minor cleanups etc. * tag 'wireless-next-2026-09-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (101 commits) dt-bindings: net: wireless: Convert WL1251 to DT schema libertas: mesh: remove unused and undocumented sysfs attribute groups wifi: mac80211: fix multi-link UHR association wifi: nl80211: rename no-ACK bitmap to TID bitmap wifi: radiotap: correct EHT TB U-SIG 1 B20:25 wifi: ieee80211: fix FTM bufferable check wifi: mac80211: allow advertising 20 MHz-only non-AP STA wifi: mac80211: WARN on 40 MHz HT/HE mismatch wifi: mac80211: tests: fix memory leak wifi: mac80211: use assign_bit() where applicable wifi: mac80211: pass error station if non-STA transmit was requested wifi: mac80211: pass station to ieee80211_tx_skb_tid wifi: mac80211: report to cfg80211 when no STA is known for a frame wifi: cfg80211: add attribute for TX/RX denoting there is no station wifi: mac80211: rework RX packet handling wifi: mac80211: refactor RX link_id and station handling wifi: mac80211: change public RX API to use link stations wifi: iwlwifi: use link_sta internally to the driver MAINTAINERS: Replace wireless.wiki.kernel.org links wifi: brcmfmac: log the firmware status when a connect fails ... ==================== Link: https://patch.msgid.link/20260921121635.195723-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-16wifi: mac80211: pass station to ieee80211_tx_skb_tidBenjamin Berg
The station may be relevant for queuing and will also generally be resolved in some cases. However, we want to be able to prevent looking up the station based on the address. Add a station parameter, which can be set to the correct station, to an error value to prevent station lookup or to NULL to get the old behaviour where the address is used to find the appropriate station. Also disable the station lookup for ieee80211_tx_skb_tid_band already as it does not make any sense to find a station when doing an off-channel transmit. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://patch.msgid.link/20260915151925.759b6144ddf9.Ib7be90db0d3712d14e7a292023ff3d922baef860@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-14wifi: mac80211: don't reset the TXQ scheduling round numberJulius Bairaktaris
A round is ended when ieee80211_next_txq() meets a txq whose remembered round number is the current one, meaning it has gone full circle. When the AC exceeds the airtime limit, ieee80211_txq_schedule_start() sets the round number to 0 to close the round. The next open round is 1. A txq from an earlier round 1 still remembers the "1", so the next round stops on it and serves nothing. Fix: use a separate open/closed flag and let the round number keep counting. Testing: ~4200 skipped selections per 20s without the fix and 20 skipped selections per 20s with the fix on ath11k (with my AQL series applied) at BE 500/1000. Fixes: 8e4bac067105 ("wifi: mac80211: add a per-PHY AQL limit to improve fairness") Assisted-by: Claude:claude-opus-5 Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de> Reviewed-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260908144155.756569-1-julius@bairaktaris.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-14wifi: mac80211: fix stats/preemption in ieee80211_tx_control_port()Deepanshu Kartikey
ieee80211_tx_control_port() can be called from nl80211_tx_control_port() in normal process context via netlink sendmsg(), where BH/preemption is not disabled. dev_sw_netstats_tx_add() uses this_cpu_ptr() internally, which requires preemption to be disabled, triggering a "BUG: using smp_processor_id() in preemptible code" warning. Fix this by moving the local_bh_disable()/local_bh_enable() section to also cover dev_sw_netstats_tx_add() and ieee80211_tpt_led_trig_tx(). Fixes: d5a014204a3b ("wifi: mac80211: tx: simplify control port frame transmission") Reported-by: syzbot+d979bd35c8a76fd1b6f5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d979bd35c8a76fd1b6f5 Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260910041047.24437-1-kartikey406@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-09wifi: mac80211: set up the TX info early to fix failure pathsJohannes Berg
The previous commit 2c51457d930f ("wifi: mac80211: free ack status frame on TX header build failure") cleaned up the leak, but still left the code a bit messy and the failed SKB didn't get reported to userspace. Fix this up by initialising skb->cb[] earlier, which allows using ieee80211_free_txskb() and therefore reports it for the failure in ieee80211_build_hdr(), and unifies the ieee80211_skb_resize() failure path with it. Assisted-by: LLM Fixes: c3e7724b6bc2 ("mac80211: use ieee80211_free_txskb to fix possible skb leaks") Link: https://patch.msgid.link/20260908122838.201719-22-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-09wifi: mac80211: don't allow injecting frames wider than the chanctxJohannes Berg
Frames injected on a monitor interface can carry a radiotap field requesting a bandwidth, which mac80211 passes down to the driver regardless of the the actual operational bandwidth. If the bandwidth requested is too wide, that triggers a warning in hwsim: WARN_ON(hwsim_get_chanwidth(bw) > hwsim_get_chanwidth(confbw)) Drop such frames entirely instead since they cannot be sent. Assisted-by: LLM Fixes: 646e76bb5daf ("mac80211: parse VHT info in injected frames") Reported-by: syzbot+435fdb053cf98bfa5778@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=435fdb053cf98bfa5778 Link: https://patch.msgid.link/20260908122838.201719-13-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-09wifi: mac80211: don't drop scan probe requests for lack of peer ratesJohannes Berg
While software scanning, ieee80211_tx_h_rate_ctrl() warns and drops the frame if the target station has no usable bitrate on the band that's currently being scanned. But that's really meant for data frames, not if we happen to scan for the BSSID on the wrong band, which can be constructed easily. Skip the check for IEEE80211_TX_CTRL_DONT_USE_RATE_MASK, the previous commit also ignored the station rate mask for such frames as well. Assisted-by: LLM Reported-by: syzbot+0d516b33238bd97ee864@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0d516b33238bd97ee864 Link: https://patch.msgid.link/20260904165722.b57ea4ab82d3.Id6c9c42d5cef5901bfac88853647b03ba4077b3e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-08wifi: mac80211: queue frames while off-channelStanislaw Gruszka
Drivers without FAST_XMIT and hardware scan support currently drop TX frames during software scanning while being off-channel. This happens in ieee80211_tx_h_check_assoc() before frames reach internal TX queue. Move the off-channel check to invoke_tx_handlers_late(), after ieee80211_queue_skb(). Frames can then remain queued and be transmitted when the interface returns on-channel. This how TX works currently when code goes via ieee80211_xmit_fast() path. Below is rt2x00 driver ping output example while scanning, before and after the fix. After the fix, packets are no longer lost. Some have increased latency, what is expected behavior. BEFORE: 64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=3.61 ms 64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=3.33 ms # Missed 30 64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=4.03 ms 64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=3.10 ms # Missed 33 64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=3.04 ms # Missed 35 64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=3.05 ms # Missed 37 64 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=4.14 ms # Missed 39 64 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=4.50 ms AFTER: 64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=3.40 ms 64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=6.10 ms 64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=4.69 ms 64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=4.49 ms 64 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=148 ms 64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=6.83 ms 64 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=8.66 ms 64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=13.0 ms 64 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=4.78 ms 64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=3.85 ms Cc: <stable@vger.kernel.org> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260908124651.2995-1-stf_xl@wp.pl Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-08mac80211: tx: Use info->flags in ieee80211_tx_h_select_key()Bert Karwatzki
Without this ieee80211_select_key_8023() is never called and wifi never connects. Fixes: 0e80db08668b ("wifi: mac80211: fix key selection for encap offload frames") Signed-off-by: Bert Karwatzki <spasswolf@web.de> Link: https://patch.msgid.link/20260908094341.12196-1-spasswolf@web.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: avoid trimming injected FCS twiceMariano Baragiola
When packet sockets use PACKET_QDISC_BYPASS, mac80211 can parse the radiotap header while selecting the queue and again before transmit. If the header includes an FCS, both parses trim the skb. Validate the FCS on both parses, but trim it only before transmit. This keeps queue selection read-only and avoids trimming shared skb data twice. Fixes: cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue") Signed-off-by: Mariano Baragiola <mbaragiola@linux.com> Link: https://patch.msgid.link/20260817233521.2747027-1-mbaragiola@linux.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: store the ack skb before building the headerJohannes Berg
The ack skb has to be stored while the frame is still in 802.3 format, since that is what is reported back to userspace. It's currently done in ieee80211_build_hdr(), but that complicates it a bit. Thanks the the previous ieee80211_lookup_ra_sta() change, it's now known whether or not the frame will be group addressed on the air, which is needed for this condition. Also simplify callers of ieee80211_store_ack_skb() by filling the TX info directly and fix the free in ieee80211_build_hdr() to use ieee80211_free_txskb(), reporting the drop to userspace rather than being quiet about it. This also lets use validate the link ID for control port TX in that code itself, rather than interleaving it into build_hdr(). Link: https://patch.msgid.link/20260803141309.292711-16-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: set flags/ctrl_flags before ieee80211_build_hdr()Johannes Berg
ieee80211_build_hdr() takes the info and control flags to use as arguments, but that leads to some messy code and missed cleanup. Fill them in the SKB before calling ieee80211_build_hdr(). Link: https://patch.msgid.link/20260803141309.292711-15-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: report multicast transmission from lookup_ra_sta()Johannes Berg
ieee80211_lookup_ra_sta() returns ERR_PTR(-ENOENT) both when the 802.11 frame will be is group addressed and when it's going to an unknown station. Keep reporting an ERR_PTR() for group addressed but set to NULL for individually addressed frames so the callers can use it to distinguish later. This is already explicitly the case for all interface types except mesh, and callers already tolerate (but don't distinguish) both cases. Also change the ieee80211_lookup_ra_sta() to be static. Link: https://patch.msgid.link/20260803141309.292711-14-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: unshare the skb before building the headerJohannes Berg
ieee80211_build_hdr() unshares the skb halfway through, after it has already looked at it but before it writes anything. That's not a problem, but complicates the callers and requires passing the flags to the function, etc. Move the unsharing to the only caller that matters, the new one from the previous patch has a fresh SKB and doesn't need it and the TDLS callers via ieee80211_tdls_build_mgmt_packet_data() are also fresh SKBs. Link: https://patch.msgid.link/20260803141309.292711-13-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: remove cookie from __ieee80211_subif_start_xmit()Johannes Berg
This argument is now always zero, so no longer used. Remove it. Link: https://patch.msgid.link/20260803141309.292711-12-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: tx: simplify control port frame transmissionJohannes Berg
ieee80211_tx_control_port() already does most of the necessary work, much of which is repeated by __ieee80211_subif_start_xmit(). Most work in the latter function is completely unnecessary since these are special frames we built directly here (long enough, etc.) Call ieee80211_build_hdr() and ieee80211_xmit() directly instead. It also means some errors can now be reported to userspace rather than frames silently getting dropped, but that's a good thing. Link: https://patch.msgid.link/20260803141309.292711-11-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: fix IEEE80211_TX_CTL_REQ_TX_STATUS mixupJohannes Berg
In ieee80211_build_hdr(), IEEE80211_TX_CTL_REQ_TX_STATUS is checked in ctrl_flags, which is wrong - IEEE80211_TX_CTL_REQ_TX_STATUS is in info->flags, so the check is for IEEE80211_TX_CTRL_PORT_CTRL_PROTO instead. This works out OK because the only place setting _that_ at a point before this gets called is in fact ieee80211_tx_control_port() which was intended here. This is actually needed for correctness, if jt were checking info->flags instead, TDLS would fill/leak the status frames created here. However, we can just fix it by using the cookie instead, that'll be set for PREAUTH frames via ieee80211_tx_control_port() as well, and no other frames. Additionally, the code also erroneously set it, but that just caused preauth frames to get it set, since storing the ACK SKB will also set the correct flag. Drop this assignment entirely. Fixes: a7528198add8 ("mac80211: support control port TX status reporting") Link: https://patch.msgid.link/20260803141309.292711-10-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: drop encap offload frames with a tainted keyJohannes Berg
When a key is tainted, which happens in some WoWLAN and extended key ID scenarios, frames that would use it should be dropped. Fix that for encapsulation offload frames. Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support") Link: https://patch.msgid.link/20260802105818.870b6ef31374.Ib87175b55b9fd94c16ba6d9cd816b7a09248df87@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: don't send encap offload frames unencryptedJohannes Berg
For 802.11 frames, ieee80211_tx_h_select_key() drops a data frame that ended up without a key if the station requires encryption, so that traffic can never leak out unprotected. Encapsulation offload erroneously didn't get this code path. Fix that. Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support") Link: https://patch.msgid.link/20260802085818.1336616-7-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: fix key selection for encap offload framesJohannes Berg
ieee80211_tx_h_select_key() assumes the frame is in 802.11 format for picking the key, at least when there's no pairwise TK for the STA to transmit with. For unicast this is likely not relevant because if there's no pairwise TK for the STA there's probably not going to be any other key either. But multicast encapsulation offload frames have no STA, so it looks at the ethernet header as if it was 802.11. This may not matter very much since multicast encapsulation offload is likely to ignore the key selection, but it's still wrong. Create a separate selection function that doesn't (need to) look at the frame header - it's data anyway, so either unicast to a station (with sta pointer) or multicast. For MLO, the driver has to duplicate the frame and select the key anyway, so just skip it in that case entirely. Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support") Link: https://patch.msgid.link/20260802105818.0feb7ad61047.Ia506ca211176a3c466bc60e4cc3e506df34a4a67@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: fix unauthorised port check for encap offloadJohannes Berg
The check in ieee80211_tx_dequeue() reads frame_control, addr1 and addr2 out of the skb, but for encapsulation offload that's just a random part of the ethernet addresses, so dropping depends on bits in the destination address. This is obviously wrong. Refactor the check and short-circuit for ethernet format frames, it only needs the port-control flag check since those are locally generated and not forwarded frames. Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support") Link: https://patch.msgid.link/20260802105818.dd5da579813d.I51ed0121154bb652bebc97bb0597b1fae9ac978f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: include TIM bitmap control for buffered S1G mcast trafficLachlan Hodges
Currently when building the S1G TIM element, we only build the bitmap control if we have buffered unicast traffic. Since AID 0 sits within the bitmap control if we have buffered multicast traffic with no buffered unicast traffic the bitmap control won't be emitted and dozing stations will be unaware of buffered multicast. To fix, only exclude the bitmap control byte when we don't have both buffered unicast and multicast traffic. Fixes: ee6360945483 ("wifi: mac80211: support block bitmap S1G TIM encoding") Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20260827054302.254124-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: mac80211: skip unused probe response countdown offsetsZhao Li
mac80211 copies cfg80211's variable-length countdown offset list into a zero-initialized fixed-size array, leaving unused entries at zero. The beacon branch already skips those zero entries, but the AP probe-response branch writes through them unconditionally. When a probe-response template has no countdown offset, the write through an unused zero entry overwrites resp->data[0], corrupting the first byte of the template. cfg80211 already bounds explicitly supplied non-zero offsets in nl80211_parse_counter_offsets(), so this is a zero-sentinel bug, not an out-of-bounds write. Skip zero probe-response offsets, matching the beacon path. Fixes: af296bdb8da4 ("mac80211: move csa counters from sdata to beacon/presp") Link: https://lore.kernel.org/all/20260708195911.84365-6-enderaoelyther@gmail.com/ Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li <enderaoelyther@gmail.com> Link: https://patch.msgid.link/20260723011001.76851-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: cfg80211: convert tx_control_port cookie to input parameterArend van Spriel
The tx_control_port op was excluded from the previous commit because a NULL cookie was affecting different behavior, ie. signalling that no TX status is wanted. Since cfg80211_assign_cookie() guarantees a non-zero value, cookie value 0 can be used instead. So pass 0 when dont_wait_for_ack is set, otherwise pass value returned from cfg80211_assign_cookie() call. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-13-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: mac80211: stop using ieee80211_mgmt_tx_cookie()Arend van Spriel
Now that cfg80211 pre-assigns the cookie before calling into mac80211, stop calling ieee80211_mgmt_tx_cookie() in all affected paths: - ieee80211_start_roc_work(): for normal ROC use the pre-assigned value directly instead of generating a new one. - ieee80211_attach_ack_skb(): the cookie is already set by the caller; remove the ieee80211_mgmt_tx_cookie() call and store it in the ack SKB as-is. This covers both mgmt_tx and probe_peer since both call ieee80211_attach_ack_skb(). - ieee80211_mgmt_tx(): the dummy 0xffffffff assignment for the dont_wait_for_ack case is no longer needed; cfg80211_assign_cookie() guarantees a non-zero value which is sufficient for the internal ROC vs mgmt-tx distinction. - ieee80211_store_ack_skb(): same fix for the tx_control_port path. With no remaining callers, remove ieee80211_mgmt_tx_cookie() and the roc_cookie_counter field from struct ieee80211_local. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-3-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02Revert "wifi: mac80211: don't encrypt pre-auth (ETH_P_PREAUTH) frames"Johannes Berg
This reverts commit dd406779999fa2065ec6b7c4f80906b727041d2c. Never encrypting the frames broke a number of tests that do additional pre-authentication while already connected, and then the frames didn't go out correctly. Whatever this was intended to fix, this wasn't the right fix. Fixes: dd406779999f ("wifi: mac80211: don't encrypt pre-auth (ETH_P_PREAUTH) frames") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-28wifi: mac80211: add ieee80211_txq_aql_pending()Felix Fietkau
Add a function to allow drivers to query the pending AQL airtime for a given txq, for both unicast and broadcast. This will be used for mt76 to limit buffering in AP mode for power-save stations. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260724115429.3921457-4-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-28wifi: mac80211: add AQL support for multicast packetsFelix Fietkau
Excessive multicast traffic with little competing unicast traffic can easily flood hardware queues, leading to throughput issues. Additionally, filling the hardware queues with too many packets breaks FQ for multicast data. Fix this by enabling AQL for multicast packets. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260724115429.3921457-3-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-27Merge tag 'wireless-2026-07-26' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== wireless-next-2026-07-26 Mostly driver changes this time: - new driver mm81x for an S1G device - new driver nxpwifi for NXP devices (mostly forked off from mwifiex) - ath12k: much kernel infrastructure integration work - brcmfmac: DPP support, some Cypress part update - nl80211: per-link statistics support ==================== Link: https://patch.msgid.link/20260726105205.942922-60-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21wifi: mac80211: don't encrypt pre-auth (ETH_P_PREAUTH) framesDeepanshu Kartikey
Pre-authentication frames (ETH_P_PREAUTH, 0x88C7) are sent before the authentication handshake completes with the target AP, so no encryption key exists for them yet. Unlike normal EAPOL frames (ETH_P_8021X, 0x888E) which are registered as the control port protocol, pre-auth frames are not recognized as control port frames, causing the kernel to incorrectly assign the current AP's key and attempt encryption, resulting in a WARN_ON in ieee80211_encrypt_tx_skb when the cipher is not handled. Fix this by setting IEEE80211_TX_INTFL_DONT_ENCRYPT for pre-auth frames in ieee80211_tx_h_check_control_port_protocol(), so that key selection skips them and they are sent unencrypted as intended. Note that the only driver hitting this path is hwsim. Reported-by: syzbot+b6ce23950fd636e6efb6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b6ce23950fd636e6efb6 Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260713015946.44636-1-kartikey406@gmail.com [add note about hwsim, fix subject] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-07wifi: mac80211: Route (Re)association req/response to per-STA queueIlan Peer
An association request or response frame is generally delivered to the driver without a TX queue object. However, with drivers that do encryption offload and couple the key with a transmit queue, this means that the frames are not being encrypted. Fix this by routing the association frames to the management TXQ. This will allow the driver to set up the required resources before transmitting the association frame, e.g., set up keys etc. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260706222925.febcc62f485c.Iff932880e4b98232cbf6ba405fbb90d650a85381@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-06wifi: mac80211: free ack status frame on TX header build failureZhiling Zou
ieee80211_build_hdr() stores an ACK status frame before it has finished all validation and header construction. If a later error path is taken, the transmit skb is freed but the stored ACK status frame remains in local->ack_status_frames. This can happen for control port frames when the requested MLO link ID does not match the link selected for a non-MLO station. Repeated failures can fill the ACK status IDR and leave pending ACK frames until hardware teardown. Remove any stored ACK status frame before returning an error after it has been inserted into the IDR. Fixes: a729cff8ad51 ("mac80211: implement wifi TX status") Cc: stable@vger.kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zhiling Zou <roxy520tt@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Link: https://patch.msgid.link/9de0423da840e92084915b8f92e66a421245c4b8.1782462409.git.roxy520tt@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10Merge tag 'wireless-next-2026-06-10' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Quite a few last updates, notably: - b43: new support for an 11n device - mt76: - mt792x broken usb transport detection - mt7921 regd improvements - mt7927 support - iwlwifi: - more kunit tests - FW version updates - ath12k: WDS support - rtw89: - RTL8922AU support - USB 3 mode switch for performance - better monitor radiotap support - RTL8922DE preparations - cfg80211/mac80211: - update UHR to D1.4, UHR DBE support - finally remove 5/10 MHz support - S1G rate reporting - multicast encapsulation offload * tag 'wireless-next-2026-06-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (285 commits) b43: add RF power offset for N-PHY r8 + radio 2057 r8 b43: add channel info table for N-PHY r8 + radio 2057 r8 b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8 b43: support radio 2057 rev 8 b43: route d11 corerev 22 to 24-bit indirect radio access b43: add d11 core revision 0x16 to id table b43: add firmware mappings for rev22 rfkill: Replace strcpy() with memcpy() wifi: brcmfmac: flowring: simplify flow allocation wifi: brcm80211: change current_bss to value wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits wifi: ath: Update copyright in testmode_i.h wifi: ath10k: Update Qualcomm copyrights wifi: ath11k: Update Qualcomm copyrights wifi: ath12k: Update Qualcomm copyrights wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checks wifi: mt76: mt7921: assert sniffer on chanctx change wifi: mt76: mt7996: fix potential tx_retries underflow wifi: mt76: mt7925: fix potential tx_retries underflow ... ==================== Link: https://patch.msgid.link/20260610103637.179340-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05wifi: mac80211: Add 802.3 multicast encapsulation offload supportTamizh Chelvam Raja
mac80211 converts 802.3 multicast packets to 802.11 format before driver TX, even when Ethernet encapsulation offload is enabled. This prevents drivers that support multicast Ethernet encapsulation offload from receiving frames in native 802.3 format. Introduce the IEEE80211_OFFLOAD_ENCAP_MCAST flag to bypass the 802.11 encapsulation step and pass the multicast packet to the driver in 802.3 format. Drivers that support multicast Ethernet encapsulation offload can advertise this flag. Disable multicast encapsulation offload in MLO case for drivers not advertising MLO_MCAST_MULTI_LINK_TX support for AP mode and for 3-address AP_VLAN multicast packets. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-4-tamizh.raja@oss.qualcomm.com [fix unlikely(), indentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Add multicast to unicast support for 802.3 pathTamizh Chelvam Raja
mac80211 already supports multicast-to-unicast conversion for native 802.11 TX paths, but this handling is missing for the 802.3 transmit path. Due to that the packet never converted to unicast and directly pass it to 802.11 Tx path by checking the destination address as multicast. Extend ieee80211_subif_start_xmit_8023() to honor the multicast_to_unicast setting by cloning and converting multicast Ethernet frames into per-station unicast transmissions, following the same behavior of the native 802.11 TX path and allow it to take 802.3 path. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Add sta pointer sanity check in ieee80211_8023_xmit()Tamizh Chelvam Raja
Currently ieee80211_8023_xmit() accesses the sta pointer without any sanity check, assuming that only unicast packets for an authorized station are processed. But the sta pointer could become NULL when a framework to support 802.3 offload for the multicast packets is added in the follow-up patches. Add the valid sta pointer sanity check to avoid the invalid pointer access. This aligns with some of the subordinate functions called by ieee80211_8023_xmit() that already NULL-check 'sta' such as ieee80211_select_queue() and ieee80211_aggr_check(). Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-2-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.1-rc7). Silent conflicts: net/wireless/nl80211.c cb9959ab5f99 ("wifi: cfg80211: enforce HE/EHT cap/oper consistency") a384ae969902 ("wifi: cfg80211: move AP HT/VHT/... operation to beacon info") https://lore.kernel.org/aiGJDaHV4UlCexIQ@sirena.org.uk Conflicts: drivers/net/wireless/intel/iwlwifi/mld/ap.c a342c99cb70d ("wifi: iwlwifi: mld: honor BSS_CHANGED_BEACON_ENABLED") 9bf1b409afc7 ("wifi: iwlwifi: mld: send tx power constraints before link activation") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk drivers/net/wireless/intel/iwlwifi/pcie/drv.c 093305d801fa ("wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used") e2323929a68a ("wifi: iwlwifi: pcie: add debug print for resume flow if powered off") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk Adjacent changes: drivers/net/ethernet/airoha/airoha_eth.c b38cae85d1c4 ("net: airoha: Fix use-after-free in metadata dst teardown") ec6c391bcca7 ("net: airoha: Introduce airoha_gdm_dev struct") drivers/net/ethernet/microchip/lan743x_main.c 8173d22b211f ("net: lan743x: permit VLAN-tagged packets up to configured MTU") e3c6508a46f5 ("net: lan743x: avoid netdev-based logging before netdev registration") Signed-off-by: Jakub Kicinski <kuba@kernel.org>