| Age | Commit message (Collapse) | Author |
|---|
|
If a custom regdomain is registered by a driver by
calling regulatory_set_wiphy_regd() (the async one)
before the wiphy is registered, and then registration
fails or it's unregistered before the worker ran, we
leak the regdomain. Free it on wiphy free.
Link: https://patch.msgid.link/20261013151817.9c197c4779d4.I983cf65a625fbc99e13b0a2710167157c34b6cd9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This is not possible by spec, so check and reject it in
order to avoid being able to hit such code paths in the
code later.
Link: https://patch.msgid.link/20261013150604.d37bf448de30.Ib47bf264ac9d2502312158503d1ca8aae99496c0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If the country data cannot be found, the function exits
and then doesn't track the SSID. Move the SSID tracking
up to fix that.
Fixes: c38c70185101 ("wifi: cfg80211: Set SSID if it is not already set")
Link: https://patch.msgid.link/20261013151258.7fbca481c328.I7beb03fb4309698bdcfade57c6804573f96eeb18@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We currently check names already in wiphy_new_nm(), but
that could technically race when two are registered at
the same time. Currently that only happens with hwsim,
which probably can't race, but it's confusing.
Do the check later, with cfg80211_mutex held, so it'll
always be precise.
Assisted-by: LLM
Link: https://patch.msgid.link/20261011113308.20e9fccb29da.I3a32d7fcfba5fd7b4ee378aa182d87e46f98c6e6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The RTNL is only used for wiphy names to serialize checking
for name collisions and setting the name, across all wiphys.
Since the wiphy list can be walked under the cfg80211_mutex,
use that instead.
In nl80211_set_wiphy() this requires taking it before the
wiphy mutex, and then the RTNL is no longer needed there at
all if the netdev is looked up under RCU. Since the netns of
the wiphy and its netdevs is now also stable under the
cfg80211_mutex, only the netdev unregistering needs to be
handled, by looking up the wdev again under the wiphy mutex.
Assisted-by: LLM
Link: https://patch.msgid.link/20261011113308.6cedefb201f4.I03ffe79f337b61ea8f91b91532d3dfb9497e0438@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The wiphy/interface netlink dumps only need the RTNL for
the list and, possibly, filtering by netdev. This can be
easily replaced now, do that.
Link: https://patch.msgid.link/20261011113308.d2b68635eeec.I42540f72c38c1bbb6edd2396d6dcc6199f1bc8c0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Hold the cfg80211_mutex across the whole netns switch, so
we can walk the wiphy list without worrying about a wiphy
switching away to a different namespace underneath. This
will allow removing RTNL from netlink dumps.
Link: https://patch.msgid.link/20261011113308.89f391aea519.I7529b9055f522cfeb8a26ae3a85c1b71a98e8192@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There's no need for the RTNL for setting SAR specs, it
seems to have just been added while I was removing the
RTNL from most places. Just drop it.
Link: https://patch.msgid.link/20261011113308.5a374e7bc350.I638c842c1639a8aa5d8207f784110b4a583aa7db@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The RTNL here is only needed for walking the wiphy list,
which can be done under cfg80211_mutex instead, we just
need to not take it in regulatory_hint_disconnect(), of
which this is the only caller.
Link: https://patch.msgid.link/20261011113308.3c7e002d1893.I31f6d1b43bb252b23b42c9b0375f557d90110dc6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We don't need the RTNL here now, all the work can happen
under RCU. Drop the RTNL and do it all under RCU instead.
Link: https://patch.msgid.link/20261011113308.ef489f51e801.Iabc6383753a9e49ade17801c76fd5a91f7397475@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In case nl80211_process_links() returns an error during
a multi-link reconfiguration request, BSS entries might
leak (if it already has one but fails on a further link).
Fix it by jumping to the out label that handles this.
Link: https://patch.msgid.link/20261010143543.184032-2-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Qualcomm reported that there can be a lot of lock
contention on the wiphy mutex due to background
processes dumping the station statistics.
In many drivers (e.g. all mac80211 drivers without
their own station statistics) it doesn't need to
be locked, the data is never guaranteed to be fully
consistent anyway given it's collected by concurrent
TX/RX.
Support unlocked get/dump station methods so that
drivers can reduce lock contention by implementing
these methods. As in the other cases, it's allowed
to return -EAGAIN if a locked call is needed.
Link: https://patch.msgid.link/20261009201417.e1d8a7d5f513.I9f6c2aff55861332c15069b9189bbf1e653648d5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Only mac80211 currently implements tx_control_port, and it
no longer needs the wiphy mutex, so don't take it here.
Link: https://patch.msgid.link/20261009201417.d89a3bc2b1ec.I30d12968a0d4ab7a4ac8d0995a9ab7583b0ce2ef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
None of the drivers implementing probe_peer (mac80211,
wil6210, nxpwifi) need the wiphy mutex for it, so we
can just not take it. Document that as well.
Link: https://patch.msgid.link/20261009201417.75233ff945c8.I2f462bfffa96feb8dcc4386bc35ebc25d877a92f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The cookie counter is currently protected by the
wiphy mutex, but in order to be able to transmit
management frames without holding that, we need
to assign cookies atomically.
Link: https://patch.msgid.link/20261009201417.ec1dbc786a60.I83ec404d833100a798181234c797c558400c7145@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Management frame transmissions need the wiphy mutex,
but the normal transmit path doesn't, so most cases
shouldn't need it here either. Due to checks, limit
it to AP/GO for now.
To support it, drivers must implement the new method
mgmt_tx_unlocked(), and return -EAGAIN from that for
requests that cannot be done without the wiphy mutex
(e.g. off-channel in mac80211), then the operation
will be retried with the wiphy mutex held.
Link: https://patch.msgid.link/20261009201417.d376c87d429b.I4acfe051ab48ea9b012aa3bb26a62ab412a6eb9b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The update-beacon operation currently can fairly easily
work without extra care and without the wiphy mutex as
it holds the netdev. However, we can't do the same now
for wdevs, they could be unregistered (and destroyed)
while the operation is running.
Allow for such operations as well by giving the wdevs a
refcount as well, and waiting for that refcount to drop
to zero during wdev unregistration.
This requires some special care in nl80211, especially
for a "re-do the operation locked" implementation, but
that's contained here so drivers need not worry about
it (except if they request the operation to be retried
under lock, that might never happen).
Link: https://patch.msgid.link/20261009201417.0eaf10071df8.If2812b7c82df39cc9ed51746f55789fc4f51d4b1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Updating beacon and related templates with NL80211_CMD_SET_BEACON
requires the wiphy mutex, which can get contended, delaying the
updates.
Add a NL80211_CMD_UPDATE_BEACON operation that can only do beacon
template updates, not other configuration changes, but is called
without the wiphy mutex. If something requires the mutex then the
driver can return -EAGAIN, to go through the normal change_beacon
with wiphy mutex held.
Also with this support updating multiple beacons for an MLD at
the same time, just to further reduce round-trips if desired.
Link: https://patch.msgid.link/20261009201417.fc5c148060cd.I174b47b65aca1bbaaf6a74d64fa0e264f84028b4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Now we have cfg80211_mutex everywhere along with wiphy mutex
for per-device bits, so don't need RTNL any more. Remove it
from the regulatory code.
Also, wiphy_apply_custom_regulatory() no longer needs the RTNL,
and get_wiphy_regdom() can no longer rely on it.
Link: https://patch.msgid.link/20261006120655.df1d3d28cfa2.I637dbd328886b52bed511fb798172a2d57521263@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
freq_reg_info() returns a pointer into the current regdomain,
so we need RTNL, cfg80211_mutex or RCU, but I want to remove
the RTNL, so just use RCU here.
Also document that this is required, we didn't say when the
function could be used at all.
Link: https://patch.msgid.link/20261006120655.c6fce71ad991.I07ae7ed37bc8ff6d75c87e19d77e4c5379a8e167@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
for_each_rdev() now requires RTNL, but we can relax that and
allow any of RTNL, cfg80211_mutex and RCU, and then use it
in quite a few more places.
Link: https://patch.msgid.link/20261006120655.1733560fc2af.I1a0c57a5d2238203b6252b189a7ca16d042888a7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The global regulatory state is currently protected by the
RTNL (which is the new BKL). Prepare for further reducing
our dependency on it by adding a new mutex that protects
this data (as well, for now held inside RTNL) and the
wiphy list (so that regulatory code can walk it).
Link: https://patch.msgid.link/20261006120655.501ac570dbcc.I5db33ad005ac5877d806e140ed0c41c464a7e5aa@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We check the DFS data for a channel under wiphy mutex, but
the code sometimes writes it under RTNL only. Fix that to
avoid data races and to prepare things for later removal
of the RTNL here.
cfg80211_dfs_channels_update_work() must change a bit more
to do this, since it locks other wiphys and nesting locks
is, while possible, too difficult: track the changes in an
array and update everything afterwards.
Link: https://patch.msgid.link/20261006120655.e90b467f7739.I9074ec4427736f66fd5d9d47a53ccd94a1f260bf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When regulatory request is intersected, the wiphy's regd
is replaced holding only the RTNL, while the non-intersected
case holds the wiphy mutex - we document access to need it.
Current readers that don't hold RTNL also don't get into it,
but it's more consistent and I want to remove the RTNL later.
Also move the similar code in reg_process_hint_driver() to
the same pattern as preparation.
Link: https://patch.msgid.link/20261006120655.a60980246fcb.Id7ac6e91aecb976f1897aa3a211a3eb7c871831e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Regulatory code updates channels holding only RTNL. Since
I removed RTNL everywhere, most reading code doesn't take
it, so it races with the updates.
Update the relevant regulatory data under wiphy mutex to
avoid (most of?) those races.
Some drivers acquire the wiphy mutex, so don't cover the
calls to the regulatory notifiers.
For beacon hints the order of operation changes, and the
driver notifier will be called only once later, but that
seems acceptable (even better) to drivers as I see it.
Link: https://patch.msgid.link/20261006120655.8c614b6d2f40.Id85777e278fbcf05b1ae1c42d2424acf6ed75fd6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Most (wdev-related) dumps also take RTNL just for lookup.
Apply the same logic as for pre_doit() in the previous
commit to avoid the RTNL. Since I refactored the checks
there into a helper to use here, it even simplifies the
code.
Link: https://patch.msgid.link/20261006120655.37954ad94c77.Ica4719b0054c949abf2528d9c4c13a5d6b7a1a49@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We currently always take the RTNL for the lookup only
to drop it again if the command doesn't want it, but
now that we can do lookups with RCU, do that unless
the command still wants RTNL anyway.
This basically just means looking up under RCU, then
holding a reference briefly, and checking state (and
link IDs) under the wiphy mutex when it's acquired to
avoid races on unregistration etc.
Commands that don't want either mutex can only work
with netdevs since wdevs could go away, so warn on
others. None such can exist since there are no flags
for it, and I noted there it wouldn't be valid.
Link: https://patch.msgid.link/20261006120655.ea80a5ecd9b8.I9c4f85fb60160f377a24c1b8e5173966744e5f09@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We already modify our wiphy/wdev lists in RCU-safe ways,
so we can do lookups in RCU critical sections. Prepare
more of the code to be able to do that.
Link: https://patch.msgid.link/20261006120655.86d9cf36d8bb.I07b7ce5a69391d5168dc31c598b5079917a29bff@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
wdev_running() uses netif_running() for netdevs, which
can only be used under RTNL in a completely race-free
way.
Track the state for all wdevs via the existing netdev
notifier so we can check the state under wiphy mutex
in later changes.
Link: https://patch.msgid.link/20261006120655.7ed32b42c297.I9ac8bb8e7cd07c962116949aa0c56aab4e87839b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
reg_query_regdb_wmm() is only used by iwlwifi, but even when
it was introduced was already broken, as it reads the global
db without any locking (drivers can't really guarantee any).
Certainly iwlwifi doesn't since it calls it for FW messages.
Therefore, it can race against regdb updates. The function
uses a local pointer, but doesn't help.
Use RCU to protect the regdb pointer to fix that, and update
the documentation to mention this (and do some cleanups).
Fixes: 19d3577e35e0 ("cfg80211: Add API to allow querying regdb for wmm_rule")
Link: https://patch.msgid.link/20261006120655.7c261d237cae.If21cf0af3b0d7e8c62c45ece5dc654b30c9d7757@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
An open debugfs file retains its file_operations pointer in the
debugfs proxy state. However, the file_operations defined by the
DEBUGFS_READONLY_FILE and DEBUGFS_RADIO_READONLY_FILE macros, as well
as ht40allow_map_ops in net/wireless/debugfs.c, have no .owner set to
THIS_MODULE.
As a result, full_proxy_open_regular() calls fops_get() which succeeds
without taking a reference to the cfg80211 module. When CONFIG_CFG80211=m
and wireless debugfs is enabled, a userspace process can open any of these
debugfs files (e.g. /sys/kernel/debug/ieee80211/phy0/rts_threshold or
ht40allow_map) and keep the file descriptor open while the module is
unloaded (rmmod cfg80211).
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/wireless/debugfs.c.
Set .owner = THIS_MODULE on all debugfs file_operations tables in
net/wireless/debugfs.c 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/20261008052936.555554-1-dungvn2345@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
WEXT IBSS and managed mode store the BSSID in the same
wdev->wext.bssid buffer. cfg80211_ibss_wext_siwap() keeps a pointer to
that buffer in wext.ibss.bssid. After changing to station mode,
cfg80211_mgd_wext_siwap() accepts a multicast AP address and copies it
to the buffer. Switching back to IBSS then follows that pointer and
uses the multicast address as a fixed BSSID.
mac80211 can create a beacon with that address, but cfg80211_get_bss()
rejects it, causing WARN_ON(!bss) in cfg80211_ibss_joined() after the
join has been reported.
Reject invalid station BSSIDs before copying them. A mac80211_hwsim WEXT
ioctl test reproduces the reported BSSID and warning; the original
syzbot report has no reproducer.
Reported-by: syzbot+d0a52209bddfa0948065@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=d0a52209bddfa0948065
Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>
Link: https://patch.msgid.link/20261007142855.1472524-1-hackerowskiy@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
That's a nonsensical configuration, and we get errors
reported further down in mac80211 for it; hostapd has
code that only adds the nested element if it'll not be
an empty list.
Remove an unnecessary NULL check while at it.
Fixes: dbbb27e183b1 ("cfg80211: support RNR for EMA AP")
Assisted-by: LLM
Link: https://patch.msgid.link/20261005224950.97db49d9d104.I5765a3310528b3d1cb1673dc90ad5ab5fc3ea571@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
As NAN beacons have a different structure compared to beacons
defined in the IEEE802.11 specification, e.g., they do not contain
a SSID element etc., they cannot be used to update the BSS table.
Add a utility function to check if a frame is a NAN beacon and
use it do return early in cfg80211_inform_bss_frame_data().
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20261005084458.3666739-5-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instant Communication requires user space to track the NAN beacons, so
fail device registration when the device declares NAN Device support
for Instant Communication but doesn't support Rx registration for
beacon frames.
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-4-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add NL80211_NAN_CONF_INSTANT_COMM flag to let user space request that
the NAN synchronization logic starts Instant Communication (IC) as
defined in Chapter 13 of the Wi-Fi Aware Specification v4.0.
Add NL80211_NAN_CAPA_INSTANT_COMM for drivers to advertise it. The
capability requires configurable synchronization support, and IC
requests are rejected if it isn't advertised.
When IC is enabled, user space must also configure the discovery
beacon interval. The IC schedule is expected to be configured
by user space.
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-2-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Protected TWT support is indicated in RSNX, but RSNX may
be used from security profile now, and not be present in
the association response frame, so the logic in mac80211
to determine it doesn't/won't really work.
Add a flag for wpa_supplicant to indicate if protected
TWT is supported in the association, it can easily check
this based on the RSNX data that was used.
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.1eb6760356f2.Ie4962eaca97be29c7f08043d615534c7aeb3f370@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
cfg80211 reports connect results and disconnects through wdev->event_list,
processed asynchronously by cfg80211_event_work(). The state that
cfg80211_connect() and cfg80211_disconnect() reason about can therefore
lag behind what the driver has already reported.
cfg80211_disconnect() relies on that asynchronous processing on purpose:
when the interface is connected it leaves wdev->u.client.ssid_len alone,
expecting __cfg80211_disconnected() to clear it later:
if (!wdev->connected)
wdev->u.client.ssid_len = 0;
If userspace reconnects before that deferred clear has run,
cfg80211_connect() installs the new SSID and the queued EVENT_DISCONNECTED
then wipes it again, together with wdev->connected, wdev->connect_keys and
wdev->conn_owner_nlportid.
The connection result of the new connection is subsequently processed with
ssid_len == 0, so the BSS lookup in __cfg80211_connect_result() cannot
match any BSS and WARN_ON(bss_not_found) triggers, dropping the connection
result and leaving userspace waiting for a connection that is never
reported. The same happens in cfg80211_roamed(). The zero ssid_len
additionally defeats the -EALREADY and connection-owner checks of the
following request, as both are skipped when ssid_len is zero.
Fix this by draining the pending events before the connect and disconnect
handlers inspect the interface state. Both run under the wiphy mutex,
which cfg80211_process_rdev_events() requires, so no new lock ordering is
introduced; this mirrors what cfg80211_change_iface() already does.
Signed-off-by: Huang Xiangping <huangxiangping88@163.com>
Link: https://patch.msgid.link/20260929035649.33538-1-huangxiangping88@163.com
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>
|
|
IEEE Std 802.11 permits the OBSS PD offset fields in the Spatial Reuse
Parameter Set element to have a value of zero. (IEEE Std 802.11-2024,
26.10.2.4)
The standard specifies the offsets as unsigned values added to -82 dBm,
with field presence signalled independently. The valid offset range is
therefore 0..20.
nl80211 currently rejects zero for all three HE OBSS PD offset
attributes during nested netlink policy validation, before the values
reach cfg80211 or the driver. Allow zero while retaining the upper bound
and the existing minimum/maximum relationship validation.
Fixes: 796e90f42b7e ("cfg80211: add support for parsing OBBS_PD attributes")
Signed-off-by: Dominic White <github@singe.za.net>
Link: https://patch.msgid.link/20260903081804.96532-1-github@singe.za.net
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>
|
|
A NAN peer that has dual radio can schedule a slot to 2 different
channels.
Until now, for single radio devices, we disallowed such a peer schedule.
This was done so because the assumption was that the user space needs to
pick one of the channels for us, according to its logic.
But for devices that have their ULW logic offloaded, it can be useful if we
program it with the full information and let it decide what to do.
For example:
- peer has slot S scheduled to C1 and C2
- local schedule has S scheduled to C1
- in practice, the device is on C2 at S, for example due to non-NAN
activity
In that case, this extra information can actually be useful to the
device, and bring to more efficient usage of the time.
Allow a peer schedule that has a single slot scheduled to two different
channels.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260922140131.6c3e3f552bda.I056644aaeea3f96605272651c4108e9ff224caf1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This is now the standard way to print data for sysfs read
callbacks.
Assisted-by: GitHubCopilot:GPT-5.3-Codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@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/20260922135556.49646df6da77.If5066fce4d8f42221009e77d76c68132e18c6a0d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
valid_regdb() walks the regulatory.db country table and returns
true as soon as either:
- a zero coll_ptr entry (the required terminator) is found, or
- the next country entry would no longer fit in the buffer.
The second case silently accepts a database image whose country
table reaches the end of the buffer without a zero-terminator.
The callers of valid_regdb() assume that every country is zero
terminated.
Exit immediately upon zero terminator, don't accept a database
without a zero terminator.
Assisted-by: GitHubCopilot:GPT-5.3-Codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@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/20260922133709.3d75b1440a1b.Ib92fa3a47e4cd5109c6139e9a4aac85c50f9be22@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In cfg80211_nan_set_local_schedule(), after calling the driver,
the old channel definitions were freed and only then the new ones were
allocated and stored.
This had two problems:
- On allocation failure the previous channel definitions had already been
freed while the driver had already applied the new schedule, leaving
the wdev with no channel definitions.
- If the driver completes a deferred schedule update synchronously,
the completion notification to user space fired before the new
channel definitions were stored, exposing an inconsistent state.
Allocate and fill the new channel definitions before calling the driver,
swap them in, and roll back on failure. Also set the pending flag before
the driver call so that a synchronous deferred completion can clear it.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260922132247.d0665fa8a5c1.I0b45103342d4a911142a2325b9259258758a0670@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Current logic only looks globally at interface counts to validate that a
monitor can have its channel configured. This works to ensure that the
wiphy is not pulled off the channel currently being used by another
active interface, but fails to allow for the case where the channels in
use on the other active interface and the desired channel for the
monitor fall on disjoint sets of radios.
Instead, search for any interface which would cause conflict, otherwise
allowing for the configuration.
Suggested-by: Dylan Eskew <dylan.eskew@candelatech.com>
Signed-off-by: Rory Little <roryl@candelatech.com>
Link: https://patch.msgid.link/20260921210441.3137-1-roryl@candelatech.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
AP power type is regulatory operating state, so changing it requires
full AP reconfiguration and validation. Allowing it through
color-change could bypass stricter checks done in AP setup.
Keep color-change behavior limited to color updates only.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@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/20260921224731.1d8727ce4fbf.I1049058ae5e60b7ebcb450d03f6b13cee573eeea@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Defer the cfg80211_reg_can_beacon_relax() check
from __nl80211_set_channel() for AP and P2P-GO.
At __nl80211_set_channel() stage AP type is not fully known
before start_ap, so this early check incorrectly rejects valid
VLP AP bring-up. start_ap has the required AP context and already
performs the regulatory validation, so start checking after start_ap.
This way, VLP APs can be brought up. Also handle the CSA scenario by
running regulatory beaconing validation during channel switch and
preserving/updating AP reg_power across CSA completion.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@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/20260921224731.67fbc8a28a2c.I5633284cb4c82ffb4e4e32e6f2dcc9a71fd5b06a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add a new NL80211_CMD_NAN_SET_NON_EVAC_CHANNELS command that lets user
space mark a set of NAN channels as non-evacuable. The command carries
the channels as nested NL80211_ATTR_NAN_CHANNEL attributes (chandef
only) and replaces the entire set of non-evacuable channels; channels
not included in the list become evacuable again.
All provided channels must already exist in the current local schedule,
otherwise -ENOENT is returned. The command is rejected with -EBUSY
while a schedule update is pending.
This prevents the kernel from evacuating channels that carry NDC or
immutable schedules, so evacuating these channels would break existing
NDP connections.
Fixes: 154b0296c0ec ("wifi: nl80211: Add a notification to notify NAN channel evacuation")
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@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/20260921215936.2efc32011e73.Ice8839058e114f6f9783079807df446388187dda@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The Control Integrity Protocol consists of a set of capabilities for the
MIC padding as well as a new CIGTK that can be installed. The CIGTK uses
a fixed GMAC-256 cipher for which no RSN extension is defined as it is
bound to the pairwise cipher being GCMP-256. The CIGTK uses the key
index 0 and 1, making it necessary to add a new key type for it.
Add a new CIP feature flag and attributes for CIP Capabilities and
enabling the feature for stations and the association.
Also extend the cfg80211 API to pass the key type rather than a single
pairwise boolean.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260921144048.aa7939493375.I49c0be0a1b05d625cc307e9bdd13c32a6c18667f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
