| Age | Commit message (Collapse) | Author |
|---|
|
The count of a netdev_hw_addr_list is changed in several places of
dev_addr_lists.c and a few drivers read it directly. The next patch
needs to account every change of the count of dev->mc.
Add __hw_addr_count_add(), __hw_addr_count_inc(), __hw_addr_count_dec()
and __hw_addr_count_reset(), use them for every change of the count
and rename the field to _count so that a direct write stands out.
Readers keep using netdev_hw_addr_list_count() and the netdev_uc_count()
and netdev_mc_count() helpers, the few that read the field directly
are converted. No functional change.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://patch.msgid.link/20261012011707.3378-3-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The code in mac80211 assumes that BSS entries are
allocated together with the struct ieee80211_bss
internal data, but the test didn't do that, which
with clang 23 resulted in a KASAN splat here. Fix
the code to properly have both structs.
Fix the allocation while at it, should be the ies
struct size, not the cbss.
Link: https://patch.msgid.link/20261013151329.b8135eb40430.I97a6cb689fbc19903c78e2f6dfe37bdc2117b605@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
BIP-CMAC-256 and BIP-GMAC append a 26-byte MME but mac80211
currently reserves only 18 bytes of encryption tailroom.
Generating 26-byte MME may happen to work because the actual skb
tailroom can exceed the requested amount. For example, dev_alloc_skb()
rounds the allocation to kmalloc size buckets or alignment boundaries,
and the extra space may cover the 8-byte shortfall.
Reserve enough tailroom for the 26-byte MME.
Fixes: 56c52da2d554 ("mac80111: Add BIP-CMAC-256 cipher")
Signed-off-by: Chien Wong <m@xv97.com>
Link: https://patch.msgid.link/20261012140738.70178-2-m@xv97.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If we fail to register the inet/inet6 address notifiers,
wiphy_unregister() is called before removing interface,
but the default interface already exists at this point.
This could also lead to a deadlock as wiphy_unregister()
then waits for the interface to go away.
Change the order to remove the interfaces first.
Assisted-by: LLM
Link: https://patch.msgid.link/20261011113308.c2cb32bf3160.Ib46993671ae3030950360ea378a507cef2bd4117@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Back when we supported algorithm switching at runtime, this
was needed for the open_count check. Now we don't have that
any more, so the check and RTNL section can go away.
Link: https://patch.msgid.link/20261011113308.0c5d35e2afea.I81141b28351e7c1ca23770616364346c33d7e08e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Implement the new cfg80211 unlocked STA statistics. If
the driver has an operation, then we need to always do
the locked again, so return -EAGAIN unconditionally if
it has a locked but not atomic operation, but drivers
can implement the new atomic methods to provide needed
data atomically (and can also return -EAGAIN).
This should, given a driver without any ops or adding
the atomic ops, reduce wiphy mutex contention.
Link: https://patch.msgid.link/20261009201417.706683ff9d81.Ieb92e4c6599a198a116fa6a4f7944219c6d32932@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Refactor the code a bit to pass around link-STA pointers
instead of looking them up again and again. This will
simplify the next changes, since otherwise all of these
lookups would have to be converted to RCU-safe ones. It
also simplifies the code generally.
Link: https://patch.msgid.link/20261009201417.32dfeaa3c44d.I7ea45bf80dd493311670f8fdd018b5c4b770a4be@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
The comment about wiphy mutex is stale since the cookie
cleanup, and everything else can be under RCU, we just
have to drop the warning in case it races AP stop.
Link: https://patch.msgid.link/20261009201417.4501c07ff31e.Ic87a72afcaea6b9a8c92f7f063bf33a2744a7992@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Implement the mgmt_tx_unlocked() method and accept frames
that are transmitted on the operating channel with it, as
they don't need further handling and can go out directly.
For off-channel etc. just return -EAGAIN to fall back to
the locked version.
Link: https://patch.msgid.link/20261009201417.6491f3bdeb4e.Ib10158e2729f89719b551dadb8384e89b9dce688@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Refactor ieee80211_mgmt_tx() into on-channel and frame
building helper functions so we can later implement the
new mgmt_tx_unlocked() method.
Link: https://patch.msgid.link/20261009201417.a84e223f4998.I4848c3eeb2aaf327712233f0bdb38bb48bdbbba6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Implement the new update_beacon() method to update beacon
and related templates without the wiphy mutex. If anything
else were to change return -EAGAIN, same if there are any
active countdowns, and during HW restart. Eventually, the
idea is to replace countdowns by beacon update requests so
hostapd can handle everything instead.
This doesn't enable it for any drivers since it depends on
the driver behaviour, if it fetches each beacon and doesn't
use the other templates it can just set the feature flag
(NL80211_EXT_FEATURE_UPDATE_BEACON), otherwise it must
implement the new update_beacon() mac80211 method.
The regular beacon update may need to take head, tail and
MBSSID/RNR elements from the old beacon, so while that's
going on mark "bss_update_in_progress" and make lockless
updates return -EAGAIN during that time, so that the old
data remains valid/identical.
For MBSSID, the lockless path also can't copy old data,
so that also has to return -EAGAIN.
All those -EAGAIN cases fall back to cfg80211 and do the
update with the lock held, where it can then be handled.
Userspace should ideally ensure it doesn't hit that path.
Assisted-by: LLM
Link: https://patch.msgid.link/20261009201417.a9433ea65d8e.Icfbcd157ac2bdeccfcc74a9f4c3997d3010ec0a9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Refactor allocating/filling beacon data to a new function,
so we can reuse it for lockless beacon updates. Also split
out the bssid_indicator calculation, lockless updates will
need to ensure it didn't change.
Assisted-by: LLM
Link: https://patch.msgid.link/20261009201417.ba48af051dfa.If468a87e4c71f8fe8d0f467525a86e7921496e9a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The AP's beacon, presp etc. templates are only updated under
wiphy mutex right now. Prepare for being able to update them
without the wiphy mutex by using a (per-link) spinlock for
them.
Link: https://patch.msgid.link/20261009201417.f9414c150e5d.Iba8a15c4d37e441642b6df68c33ef8c97340e9a9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
An open debugfs file retains its file_operations pointer in the
debugfs proxy state. However, hwflags_ops in net/mac80211/debugfs.c
has no .owner set to THIS_MODULE.
As a result, full_proxy_open_regular() calls fops_get() which succeeds
without taking a reference to the mac80211 module. When CONFIG_MAC80211=m
and wireless debugfs is enabled, a userspace process can open the
hwflags debugfs file and keep the file descriptor open while the module
is unloaded (rmmod mac80211).
When the userspace process subsequently closes the descriptor,
full_proxy_release() accesses the already unmapped file_operations
structure, triggering a kernel oops in full_proxy_release():
BUG: unable to handle page fault for address: fffffbfff8056f03
#PF: supervisor read access in kernel mode
Oops: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:full_proxy_release+0x8e/0x140
Call Trace:
<TASK>
__fput+0x39f/0xa60
fput_close_sync+0xff/0x200
__x64_sys_close+0x8c/0xf0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
The issue was discovered via manual code audit of
net/mac80211/debugfs.c.
Set .owner = THIS_MODULE on hwflags_ops so that debugfs pins the
module until all open file descriptors have been closed.
Signed-off-by: Bui Viet Dung <dungvn2345@gmail.com>
Link: https://patch.msgid.link/20261008052412.541780-1-dungvn2345@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
ieee80211_inform_bss() currently calls ieee802_11_parse_elems to
parse the beacon elements, which internally sets the params->mode
to IEEE80211_CONN_MODE_HIGHEST. This means any S1G specific parsing
is bypassed entirely (in the beacon case it is the shorter TIM)
and the beacon is marked as corrupt:
wlan0: operating as S1G STA
wlan0: associating to AP 0c:bf:74:00:30:fd with corrupt beacon
wlan0: associate with 0c:bf:74:00:30:fd (try 1/3)
In this case, we can simply call ieee802_11_parse_elems_full and
build the params locally (similar to most mlme paths) such that we
can set the conn mode to ensure the S1G specific parsing occurs.
Once this is done, the beacon is no longer considered corrupt:
wlan0: operating as S1G STA
wlan0: associate with 0c:bf:74:00:30:fd (try 1/3)
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20261008030939.474493-3-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
An S1G TIM, unlike the regular TIM, can exclude both the bitmap
control and the PVB. As a result it's minimum length is actually 2.
Fix this by allowing a shorter TIM for S1G connections.
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20261008030939.474493-2-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
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>
|
|
These structs are placed after the tail, but that can make
them unaligned. Change the order so the structs are after
one another, and then followed by the head/tail/elements.
Assisted-by: LLM
Fixes: 2b3171c6fe0a ("mac80211: MBSSID beacon handling in AP mode")
Link: https://patch.msgid.link/20261005224950.2f554b2c7c10.Ie961eb6b1435f956446e052936258758b966c67f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The mesh and MPP path generation counters (for netlink)
are updated wrongly and sometimes unlocked. Fix those
issues.
Assisted-by: LLM
Link: https://patch.msgid.link/20261005224950.373dd5c1e46a.I29b95bc3f62b846084700599a261a203a6e459b4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
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>
|
|
We never kill the wake_txqs_tasklet so it could be running
while the hardware is being freed. Kill it, late enough to
never be able to restart afterwards.
Assisted-by: LLM
Fixes: 21a5d4c3a45c ("mac80211: add stop/start logic for software TXQs")
Link: https://patch.msgid.link/20261005224950.3fdb8d0ff377.I851e79ac625c4926e211642ee7a7e458728b0ad3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The mesh paths walk list used under RCU, so we must use
hlist_add_head_rcu() to publish an entry. Fix one place
that didn't do that.
Assisted-by: LLM
Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
Link: https://patch.msgid.link/20261005224950.e0db543145e1.Ieaf30d3546e8ff63ccf400f6fb26e027c218721f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In practice, we probably shouldn't end up with a fragmented
frame that's protected, filled into the cache, finished or
dropped and then the next frame is unprotected, since only
unicast data frames can be fragmented.
However, tools complain and it's more correct to be able to
do this (e.g. an unencrypted fragmented EAPOL _could_, at
least in theory, happen), so clear the flag when the entry
is reused.
Assisted-by: LLM
Fixes: 7e44a0b597f0 ("mac80211: prevent attacks on TKIP/WEP as well")
Link: https://patch.msgid.link/20261005224950.c3e4106f34d5.I866c0862db031c3a810d2333acdd22e2733d2b8c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Cross-merge networking fixes after downstream PR (net-7.3-rc7).
Conflicts:
include/net/strparser.h
0984ebc631792 ("strparser: make sure __strp_recv isn't running before tearing down the parser")
02fd0a2111374 ("net: strparser: removed the aborted bit and aborts counter")
https://lore.kernel.org/asYfmLsfy-SCxXjr@sirena.co.uk
Adjacent changes:
Documentation/networking/strparser.rst
5f193cdabf25 ("docs: networking: strparser: remove general mode")
0984ebc63179 ("strparser: make sure __strp_recv isn't running before tearing down the parser")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ieee80211_fill_rate_info() copies the driver's rate_info bandwidth into
the rx_status as is, but ieee80211_get_rate_duration() only handles
20/40/80/160/320 MHz. When a driver reports another width, e.g. an
HE/EHT RU allocation, it hits WARN_ON_ONCE() and returns 0 without
setting *overhead. ieee80211_rate_expected_tx_airtime() then goes on
using the uninitialized overhead, as Dan's static checker report
points out.
Seen on a Microsoft Surface Pro 11 (WCN7850, ath12k) while
NetworkManager dumps station info:
WARNING: net/mac80211/airtime.c:532 at ieee80211_get_rate_duration.isra.0+0xc0/0x180 [mac80211]
ieee80211_get_rate_duration.isra.0+0xc0/0x180 [mac80211]
sta_estimate_expected_throughput.isra.0+0x38/0x64 [mac80211]
sta_set_sinfo+0x7fc/0x8e4 [mac80211]
ieee80211_dump_station+0x4c/0x84 [mac80211]
nl80211_dump_station+0x594/0x7e8 [cfg80211]
Only accept widths that ieee80211_get_rate_duration() handles in
ieee80211_fill_rate_info(). Other widths then give no estimate instead
of a warning. Also return 0 from ieee80211_rate_expected_tx_airtime()
when no duration could be computed, as ieee80211_calc_rx_airtime()
already does.
Tested on the Surface Pro 11 with next-20260929: Wi-Fi works and
"expected throughput" is still reported (about 1049 Mbit/s for a
1297 Mbit/s HE 160 MHz tx rate). The warning itself is rare (twice in
several days of use), so this does not prove it is gone, only that the
change does not break the normal path.
Fixes: 094dc1619cb0 ("wifi: mac80211: factor out part of ieee80211_calc_expected_tx_airtime")
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/all/aneGlCMVnqRhlf6p@stanley.mountain/
Assisted-by: LLM
Signed-off-by: François Roux <franzelfranzel@gmail.com>
Link: https://patch.msgid.link/20261006083751.4015-1-franzelfranzel@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
When netdev registration fails or an interface cannot be moved out of a
dying network namespace, the netdev core calls ->ndo_uninit()
(ieee80211_uninit) with RTNL held.
However, ieee80211_uninit() calls ieee80211_teardown_sdata() without
holding wiphy_lock. During teardown, ieee80211_free_keys() invokes
wiphy_delayed_work_cancel(), which triggers a lockdep warning:
WARNING: CPU: 0 PID: 6112 at net/wireless/core.c:1839 wiphy_delayed_work_cancel+0x85/0xb0
...
Call Trace:
ieee80211_free_keys+0x31a/0x3c0 net/mac80211/key.c:380
ieee80211_teardown_sdata+0x2b8/0x10f0 net/mac80211/iface.c:928
ieee80211_uninit+0x3f/0x50 net/mac80211/iface.c:954
rollback_registered_many+0xa5c/0xef0 net/core/dev.c:10065
In the normal deletion path (ieee80211_del_virtual_intf), both RTNL and
wiphy_lock are held when ieee80211_teardown_sdata() runs, and the sdata
is removed from local->interfaces.
Change ieee80211_unlist_sdata() to return a boolean indicating whether the
sdata was present in the list, and acquire wiphy_lock in ieee80211_uninit()
only if the interface is actually being unlisted here.
Reported-by: syzbot+e9cbd080a7801f06cf08@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e9cbd080a7801f06cf08
Tested-by: syzbot+e9cbd080a7801f06cf08@syzkaller.appspotmail.com
Signed-off-by: Raj Ojha <rajojha047@gmail.com>
Link: https://patch.msgid.link/20261003112741.52-1-rajojha047@gmail.com
[dissolve ieee80211_unlist_sdata() to avoid weird locking]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In mac80211 the deflink link IDs for non-MLO are set to
zero to match the array index where their pointer lives.
However, the rx->link_id is expected to be -1 in these
cases, so just mapping it to the link/sta_link link_id
broke a few things such as reporting of spurious 4-addr
frames.
Set the link ID to -1 in these cases.
Reported-by: Jouni Malinen <j@w1.fi>
Fixes: 6d531b9af16e ("wifi: mac80211: rework RX packet handling")
Link: https://patch.msgid.link/20261005114413.816905704456.Ib59a1ecce6ad74b23e4382e03cf3c113cbbdea2e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Accept NAN beacons in the Rx path only when Instant Communication
(IC) is enabled in the NAN configuration.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20261005084458.3666739-7-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instant Communication requires user space to track the NAN beacons, so
let it register for Rx of beacons on a NAN interface.
Assisted-by: GitHubCopilot:claude-opus-5
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261005084458.3666739-6-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Copy the Instant Communication flag when storing the NAN
configuration.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261005084458.3666739-3-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When a BSS color change starts, mac80211 tells the driver that the BSS
color is disabled, as the Beacon frames say during the countdown, but it
also sets the color to 0. While the BSS Color Disabled subfield is 1, an
HE STA shall keep using its nonzero color, the one it used before, in the
BSS_COLOR of the HE PPDUs it transmits (IEEE Std 802.11-2024, 26.11.4),
and a driver can only do so if it still knows the color.
Keep the current color and only clear enabled.
Assisted-by: LLM
Signed-off-by: Andrei-Alexandru Bleortu <me@andrei-z.com>
Link: https://patch.msgid.link/e696e399eee2f42c2907c45c85aa894705bee1bf.1791111135.git.me@andrei-z.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The else-if branch condition 'old && old->mbssid_ies' already
guarantees 'old' is non-NULL. The inner 'old &&' in
'if (old && old->rnr_ies)' is therefore redundant; remove it.
Signed-off-by: Aloka Dixit <aloka.dixit@oss.qualcomm.com>
Link: https://patch.msgid.link/20261002-csa_cca_fix-v1-2-b83a998aeb44@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Commit a519be2f5d95 ("wifi: mac80211: do not use old MBSSID
elements") fixed the incorrect inclusion of stopped/removed
non-transmitted profiles from the Beacon frames, but it caused
a regression for channel switch (CSA) and BSS color change (CCA)
operations initiated from hostapd.
Hostapd passes two Beacon templates to kernel for CSA and CCA -
(1) beacon_csa/beacon_color_change used during the countdown.
(2) beacon_after/beacon_next used after the countdown completes.
Hostapd relies on the kernel to include the old MBSSID elements
while sending beacon_csa/beacon_color_change templates to the
driver.
This path is now broken and results in CSA/CCA failure.
Including existing MBSSID elements explicitly makes the netlink
buffer larger than default 4 KB depending on the number of APs
which would need unnecessary complication to pre-calculate the
buffer length.
Revert the commit to fix the regression.
Regarding the original issue fixed by the reverted commit -
Hostapd now has a new commit which always includes at least one
MBSSID element when the feature is enabled, hence when all
non-transmitted profiles are removed, this empty element ensures
that stopped profiles are not advertised.
Fixes: a519be2f5d95 ("wifi: mac80211: do not use old MBSSID elements")
Signed-off-by: Aloka Dixit <aloka.dixit@oss.qualcomm.com>
Link: https://patch.msgid.link/20261002-csa_cca_fix-v1-1-b83a998aeb44@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
According to IEEE Std 802.11-2024, subclause 11.45.2.1 FILS Discovery
frame transmission, only a transmitting BSS shall transmit a FILS
Discovery frame. Currently, BSS_CHANGED_FILS_DISCOVERY is set
unconditionally for all the BSSs. Hence, add a check to allow setting
the FILS Discovery flag only for a transmitting BSS.
Similarly, IEEE Std 802.11-2024, subclause 26.17.2.3.2 AP behavior for
fast passive scanning, mentions that unsolicited broadcast probe
response frame shall be transmitted only by a transmitting BSS. Hence,
add a check to allow setting the BSS_CHANGED_UNSOL_BCAST_PROBE_RESP only
for a transmitting BSS.
Currently in user-space there is no restriction on sending this for
non-transmitting BSS, thus it may send these for those BSSs as well.
While this is not a valid configuration, returning an error here could
be fatal because failing 'start_ap' or 'update_ap' operation would result
in failure of bringing up those BSSs. Thus, to maintain the compatibility
with existing user-space, ignore the config for non-transmitting BSS silently.
Signed-off-by: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>
Link: https://patch.msgid.link/20261001-fils-v3-1-55c5628f9d1d@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The regulatory connectivity element is informational and for
debug, per spec, but that didn't stop some situations/tests
from requiring certain bits to be set, notably the SP bit to
be set if any channel is available for AFC client behaviour,
even if that seems to reduce the utility of the bit.
Set the bit accordingly by initialising the flags to NO_AFC
and then masking for all enabled channels.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260930120507.2ba7e2905019.I6d589cf60434ba9d3e007fe4537c8c8e2aeb7415@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The "twt_protected" flag in the link/bss_conf information
really isn't right since this is negotiated via RSNX and
therefore cannot differ per link. Move it to be a per-STA
indication and also derive it from the new assoc request
flag since that gets used with security profile.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260930120021.844fde440b63.I80999965c70e50d756ab62833fc7f53f2481cf3d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Type-check element finding functions and element iteration macros,
so that when constants are given for the (extended) ID they must
be from the appropriate enum, otherwise an enum compare compiler
warning will trigger.
Two places are using element iteration for subelements, but don't
have the outer element as a struct element, so they need casts to
avoid the warning now, but overall this will flag issues like the
one in the previous commit.
Link: https://patch.msgid.link/20260928193832.706fb927f309.I0f8702dc218b56470017d2fcf8fff2980946e818@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
WLAN_EID_TX_POWER_ENVELOPE is a regular (non-extended) element,
but I accidentally used cfg80211_find_ext_elem for it, and it
should be a loop since multiple can be given. Fix both issues.
Link: https://patch.msgid.link/20260928193832.a3deb0415eaf.I8b07b323ba83173b570bc07ed61f4130b8aff04f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Do not report NL80211_STA_INFO_BSS_PARAM for station information
generated on AP interfaces, as beacon interval, DTIM period, CTS
protection, short preamble and short slot time are AP BSS configuration
parameters already managed by userspace.
Retain BSS parameter reporting for STA interfaces, where these
parameters describe the BSS to which the station is associated.
Use the per-link BSS configuration when populating BSS parameters for
STA link station information.
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Link: https://patch.msgid.link/20260928101506.726663-1-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter/IPVS fixes for net
The following batch contains Netfilter fixes for net. This batch
fixes crashes as recent feature regression, one of the due to a
dependency that has been pulled into -stable:
1) Expand existing ipset fix for bitmap sets to disallow comments
updates from kernel-side adds, from Florian Westphal.
2) Drop flowtable reference if nf_ct_netns_get() fails, otherwise
flowtable cannot ever be removed, from Aohan Mei.
3) nft_rbtree GC should collect end elements that contained in
this transaction batch, new or deleted elements are never
expired. From Weiming Shi.
4) Restrict nf_nat_bpf so it does not set unknown NF_NAT_MANIP_*
values, from Fernando F. Mancera.
5) Flowtable GC must skip flows that are pending hardware updates,
generalize the PENDING flag and use it to inhibit GC.
6) Restore flowtable with ieee80211 which broke due to a relatively
recent commit, which was pulled in by -stable, causing a regression
in 6.18 kernels.
And the following IPVS fixes:
1) Fix accounting of cache entries in IPVS LBLC for destinations,
which eventually fills up the table and trigger recurrent
resizing, from Julian Anastasov.
2) Limit IPVS cache growth for LBLCR and LBLC schedulers,
from Zhiling Zou.
3) Restrict IP_VS_CONN_F_ONE_PACKET for normal connections,
do not allow to use it with templates. Also from Julian.
4) Sanitize flags in IPVS sync messages received in the backup.
From Julian Anastasov.
netfilter pull request 26-09-30
* tag 'nf-26-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: flowtable: restore ieee80211 forward path
netfilter: flowtable: generalize pending status bit
netfilter: bpf: reject invalid NAT manipulation types
netfilter: nft_set_rbtree: skip transaction elements during GC
ipvs: filter some flags received in the backup server
ipvs: do not create invisible templates
ipvs: bound LBLCR and LBLC cache growth
ipvs: fix missing counter decrement in lblc
netfilter: nft_flow_offload: drop flowtable reference on init error path
netfilter: ipset: do not update comments from kernel-side adds
====================
Link: https://patch.msgid.link/20260930074142.298353-1-pablo@netfilter.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Before commit 871df5007eda ("netfilter: flowtable: bail out if forward
path cannot be discovered"), there was a fallback to set up a forward
path in case .ndo_fill_forward_path fails or DEV_PATH_MTK_WDMA was used.
Such fallback was used by commit d787a3e38f01 ("mac80211: add support
for .ndo_fill_forward_path").
One possibility is to handle DEV_PATH_MTK_WDMA from the flowtable
forward path discovery. However, this is only used internally by drivers
to retrieve mtk_wdma information to set up hardware offload. Felix
decided to use the .fill_forward_path interface for this purpose due to
the lack of a better interface at that time.
Add a new DEV_PATH_IEEE80211 path which is offered if the new ieee80211
flag is set on in the struct net_device_path_ctx to restore the
flowtable with a ieee80211 netdevice. Handle this new DEV_PATH_IEEE80211
path just like DEV_PATH_ETHERNET and DEV_PATH_DSA, ie. this is the last
netdevice in the stack.
This new ieee80211 flag is implicitly unset for mtk_ppe and airoha which
call dev_fill_forward_path() to retrieve a DEV_PATH_MTK_WDMA path.
Fixes: 871df5007eda ("netfilter: flowtable: bail out if forward path cannot be discovered")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
When an association with AP times out, and the connection is an
Enhanced Privacy Protection (EPP) connection where the TK is already
installed, send an explicit deauthentication frame to the AP so it
would clear its local state. Not doing so might impact (fail) future
connection attempts with this AP (that might think that the station
is still connected).
This cannot be done by user space, since as part of the association
timeout flow, the station and corresponding keys are removed.
Assisted-by: GithubCopilot:claude-opus-5.0
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/20260926212249.736b01b4a76d.Ie528ea57d4d8dc8abfca406f8bae55a3902ff740@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When an interface owning the active hardware ROC is purged, a ROC
queued for another interface can become the head of roc_list without
being started. Subsequent requests only append to the non-empty list,
so no driver work is scheduled and the entries are never freed.
Flush pending ROC start work and cancel pending completion work before
handing the remaining queue to the normal next-ROC path. This preserves
the existing software ROC handling and avoids stale workers operating
on the newly started ROC.
Reported-by: Vega <vega@nebusec.ai>
Assisted-by: LLM
Signed-off-by: Ruide Cao <caoruide123@gmail.com>
Signed-off-by: Ren Wei <weir@nebusec.ai>
Link: https://patch.msgid.link/6975ce9d8e9a153e8319d10e6e7c7be004d6df88.1787220252.git.vega.cover-letter@nebusec.ai
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
