Florian Fainelli says:
====================
net: broadcom: Couple of minor changes
The first change makes sure there is proper reference counting handling
in case of error/removal for the bcmsysport driver.
The second change removes duplicates definitions in the ASP2 driver.
====================
Link: https://patch.msgid.link/20260922222525.3992167-1-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In bcm_sysport_probe(), priv->phy_dn is only initialized if the device
tree node has a fixed-link configuration (of_phy_is_fixed_link). When
connecting to a discrete MDIO-attached PHY referenced via 'phy-handle',
priv->phy_dn remains NULL. This causes of_phy_connect() during
bcm_sysport_open() to fail with -ENODEV since of_phy_find_device(NULL)
returns NULL.
Fix this by parsing 'phy-handle' via of_parse_phandle() and falling back
to of_phy_is_fixed_link(). Ensure proper of_node_get() and of_node_put()
refcounting lifecycle on both error unwinding and module remove paths.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260922222525.3992167-2-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet says:
====================
vxlan: convert configuration to RCU and enable lockless dumps
This patch series converts struct vxlan_config to RCU protection, eliminates
redundant destination fields, and enables lockless RTNL-free link dumping
in vxlan_fill_info().
====================
Link: https://patch.msgid.link/20260922181102.3989489-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that vxlan->cfg is RCU-protected, we can update vxlan_fill_info()
to run under RCU read lock instead of relying on RTNL.
This completes the transition to RTNL-less link info dumping for VXLAN.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-9-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that vxlan->cfg is an RCU-protected pointer, storing default
destination attributes (remote_ip, remote_vni, remote_ifindex) in
vxlan->default_dst is redundant and creates potential data races for
lockless readers.
Furthermore, several fields of struct vxlan_rdst (remote_port,
offloaded, list, rcu, dst_cache) in default_dst were completely unused.
The remaining one, remote_dev, only tracked the lower device, a role
now taken by vxlan->lowerdev, so drop it from struct vxlan_rdst.
Replace vxlan->default_dst with a 'struct net_device *lowerdev' pointer
in struct vxlan_dev to track adjacent upper/lower netdev topology under
RTNL, and switch all remaining users over to reading configuration
attributes from vxlan->cfg.
Also update mlx5e_tc_tun_get_remote_ifindex() to read remote_ifindex
from vxlan->cfg under rcu_read_lock().
In vxlan_changelink(), pass lowerdev to vxlan_config_apply() to preserve
needed_headroom and needed_tailroom. The mtu is still only reconsidered
when the lower device changes, so that an unrelated changelink can not
shrink it.
cfg->remote_ifindex is now committed unconditionally, where
default_dst.remote_ifindex was left untouched when IFLA_VXLAN_LINK was
cleared, so a changelink dropping the lower device no longer leaves a
stale ifindex behind. For the same reason vxlan_changelink() no longer
needs to compute the ifindex that will actually be committed.
Setting IFLA_VXLAN_LINK to 0 now also tears down the upper/lower
adjacency, which netdev_adjacent_change_commit() used to skip for a NULL
new device, resets needed_tailroom, and is rejected if per-VNI multicast
groups are configured.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-8-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Move 'struct vxlan_config' from an embedded structure inside
'struct vxlan_dev' to a dynamically allocated RCU-protected pointer
'vxlan->cfg'.
Updating configuration via vxlan_changelink() or vxlan_dev_configure()
allocates a new struct vxlan_config and publishes it with
rcu_assign_pointer(), freeing the previous config with kfree_rcu().
Readers are converted to use rcu_dereference() or rtnl_dereference().
In vxlan_xmit(), acquire rcu_read_lock() to protect config access.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-7-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
VXLAN_F_MDB is an internal runtime state flag indicating whether any
MDB entries are configured on the device, rather than a netlink
configuration attribute.
In preparation for converting vxlan->cfg to an RCU-protected pointer,
move VXLAN_F_MDB from struct vxlan_config to a dedicated 'flags' field
in struct vxlan_dev as VXLAN_DEV_F_MDB, using atomic bitops (set_bit(),
clear_bit(), test_bit()) to avoid KCSAN data races between the TX path
and RTNL operations.
This avoids having to dynamically reallocate and publish a new
vxlan_config structure via RCU whenever the first MDB entry is added
or the last one is removed, and prevents potential memory allocation
failures during MDB teardown under memory pressure.
mlxsw validates cfg->flags against a deny-by-default mask, so
VXLAN_F_MDB used to make mlxsw_sp_nve_vxlan_can_offload() reject a
device with MDB entries as carrying an unsupported flag. Add an
explicit VXLAN_DEV_F_MDB test there to keep that rejection, with a
message naming the actual reason.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-6-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In preparation for converting vxlan->cfg to an RCU-protected pointer,
refactor internal helper functions in the RX, TX, MDB, and VNIFILTER
paths to accept a pointer to struct vxlan_config (or pass flags/
saddr_family where appropriate) rather than directly accessing
vxlan->cfg.
No functional changes.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-5-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
vxlan_vnifilter_dump() walks all vxlan devices of a netns, and for each
one walks vg->vni_list. Both cursors are plain ordinals stored in
cb->args[0] and cb->args[1], and RTNL is released between dump skbs.
A concurrent __vxlan_vni_add_list(), which inserts sorted by VNI,
__vxlan_vni_del_list(), or an in-place group update in
vxlan_vni_update() (which splits or merges coalesced VNI ranges) shifts
the second cursor, duplicating or skipping entries. Unregistering a
vxlan device shifts the first one, and the partially dumped device is
then skipped altogether by the "if (idx < s_idx)" test, silently losing
the rest of its VNIs.
Add a per-netns generation counter, bumped whenever the set of vxlan
devices in the netns or any vni_list changes, and feed it to
nl_dump_check_consistent() so that user space gets NLM_F_DUMP_INTR and
can retry, as vxlan_mdb_dump() already does.
The counter is keyed on dev_net(vxlan->dev) rather than vxlan->net,
because the dump enumerates devices with for_each_netdev_rcu() in the
netns the netdevice lives in, which differs from the packet i/o netns
when the device was created with a separate link netns.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-4-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
RTM_GETTUNNEL dumps currently run under RTNL lock, but
vxlan_vnifilter_dump() also acquires rcu_read_lock().
1) Currently vxlan_vnifilter_dump_dev() traverses vg->vni_list using
list_for_each_entry_safe(). Even though RTNL is held today, writers
modify vg->vni_list with list_add_rcu() and list_del_rcu().
Switch to list_for_each_entry_rcu() for proper RCU traversal and
as preparation for future lockless dump support.
2) During a paginated dump, RTNL is released between dump skbs.
If vxlan_vnifilter_dump_dev() returns early because VXLAN_F_VNIFILTER
is not set or vg has no VNIs, cb->args[1] was not cleared. This leaked
a non-zero VNI offset to subsequent devices, silently skipping their
first N VNIs.
Furthermore, if devices are added or removed between dump calls,
ordinal device indexes can shift. Track the current device ifindex
in cb->args[2] and reset cb->args[1] if the device changes.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
vxlan_changelink() only refreshed the default fdb entries when the
remote IP changed, but vxlan_config_apply() also updates
default_dst.remote_ifindex when the lower device changes. A changelink
that only swaps the lower device therefore left the all zeros mac rdst
pointing at the old ifindex:
ip link add vxlan0 type vxlan id 10 group 239.1.1.1 dev eth0
ip link set dev vxlan0 type vxlan group 239.1.1.1 dev eth1
vxlan_xmit_one() uses rdst->remote_ifindex as the route oif, so traffic
kept leaving eth0.
VNI filter entries have the same problem, and are worse: their fdb
entries are keyed on the device remote_ifindex even when the vni
carries its own group, but vxlan_vnilist_update_group() only visited
the vnis without one. vxlan_vni_delete_group() later looks an entry up
with the current remote_ifindex, and vxlan_fdb_find_rdst() requires an
exact match, so the lookup failed and the entry survived the delete.
Re-adding the same vni then appended a second rdst, duplicating
transmitted BUM traffic.
Likewise, in vxlan_vni_update_group(), oldrip was only set when newrip
was NULL, so changing an existing VNI's group appended the new rdst
without deleting the old one. Set oldrip to the previous effective
remote IP whenever updating an existing VNI (!create).
Pass the old and new ifindex down to vxlan_update_default_fdb_entry()
so the append targets the new lower device and the delete still matches
the entry created for the old one, and refresh every vni rather than
only those inheriting the device group. If updating the vni list fails
partway through, unwind the already updated fdb entries (still deleting
the new rdst even if re-adding the old one fails) so default_dst and
the fdb entries do not diverge.
Also run vxlan_multicast_leave() and vxlan_multicast_join() when
VXLAN_F_VNIFILTER is set so per-VNI multicast memberships are migrated
even when the device default remote_ip is not multicast, and make
vxlan_multicast_leave_vnigrp() skip the default group and ignore
-EADDRNOTAVAIL when multiple VNIs share a multicast group.
The new ifindex is the one vxlan_config_apply() will commit, which is
the current one when lowerdev is NULL, so that default_dst and the fdb
entries can not diverge.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
hinic3_init_hwdev() stores the result of hinic3_adev_idx_alloc() in
hwdev->dev_id without checking for an error. If ID allocation fails but
the remaining initialization succeeds, hinic3_add_one_adev() uses the
negative error code as the auxiliary device ID instead of a reserved ID.
Return the allocation error before initializing the hardware. Add an
unwind label that clears pci_adapter->hwdev and frees the allocation
without attempting to release an ID that was never allocated.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Reported-by: Changyul Lee <lcy8047@gmail.com>
Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com>
Link: https://patch.msgid.link/179001656835.91284.3719235813225229273.idr-bug-81@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After conntrack NAT rewrites a packet, OVS refreshes the cached flow
key in ovs_nat_update_key(), which has a per-protocol branch for the
L4 ports (UDP/TCP/SCTP, conntrack.c). Address-only NAT cannot tell a
working SCTP branch from a missing one: the ports survive unchanged
either way, so a post-recirc match on the original port stays green
even with the branch deleted. The suite's NAT coverage drives TCP
over nc, and the merged SCTP test has no conntrack in the path, so
the SCTP branch goes unexercised.
Add test_sctp_nat_connect_v4: untracked client traffic to
192.168.0.20:4443 hits ct(commit,nat(dst=172.31.110.20:5555)),recirc,
and the post-recirc flows match the translated tuple,
ipv4(dst=172.31.110.20),sctp(dst=5555). Reply traffic is matched on
the restored original tuple, sctp(src=4443). With the SCTP branch
broken the translated port never reaches the key, no post-recirc
flow matches, and the association fails. The probe flow uses the
same ct+nat action as the real flows, so a kernel without
CONFIG_NF_NAT rejects it at flow-add time and the test skips instead
of failing. The config fragment sets CONFIG_NETFILTER_ADVANCED=y so
CONFIG_NF_CT_PROTO_SCTP is visible, CONFIG_NF_CT_PROTO_SCTP=y, and
CONFIG_NF_NAT=m so the reference build actually has those pieces.
After the association succeeds the test pushes a known payload
across and waits for the listener to log it.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Narcisa Vasile <narcisav.kernel@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260918144647.2024095-3-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The merged SCTP test covers only IPv4. The SCTP branch of the IPv6
extractor (the proto=132 walk after parse_ipv6hdr) and the v6 side of
the SCTP netlink validation (match_validate() requires the sctp() key
whenever ipv6(proto=132) is matched) have no selftest coverage.
Add test_sctp_connect_v6 mirroring the v4 test: bare icmpv6() flows
forward NS/NA, and ipv6(proto=132),sctp(dst=4443)/sctp(src=4443)
flows gate the association in the same three phases (flows installed,
removed, reinstalled). A keyless ipv6(proto=132) install must be
refused with EINVAL, pinning the reject side of the match_validate()
rule; without it a regression dropping the requirement would pass
unnoticed. The refusal is asserted to be EINVAL specifically, not a
parse error of the flow string. After the association succeeds the
test also pushes a known payload across and waits for the listener
to log it, proving the datapath carries the association's traffic
end to end, not only its handshake. Skips when the sctp module is
missing, socat lacks SCTP or IPv6 support, or IPv6 is unavailable;
an association or payload failure with the flows installed fails
the test.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Narcisa Vasile <narcisav.kernel@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260918144647.2024095-2-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For ath10k, document NVMEM device tree bindings.
For ath11k, fix an error path resource leak.
For ath12k, fix monitor RX buffer lifecycle issues, properly align QMI
memory to meet firmware requirements, extend datapath device stats
coverage, and a few other cleanups.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCarln3AAKCRAsFbugiYzL
ewvsAP0ZJbiy/TgZdDGdcT1eqzkPcGm5xcIlf1SjxEpVpXYC+gD+KadlhSk6KkLZ
TCLJPcK9YXRP+SDfB8mmLrM7dKk//wk=
=y2fT
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20260927' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git patches for v7.4 (PR #2)
For ath10k, document NVMEM device tree bindings.
For ath11k, fix an error path resource leak.
For ath12k, fix monitor RX buffer lifecycle issues, properly align QMI
memory to meet firmware requirements, extend datapath device stats
coverage, and a few other cleanups.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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>
lbs_process_rxed_packet() computes the packet header pointer as
skb->data + rxpd->pkt_ptr, where pkt_ptr is a 32-bit value supplied
by the device, and never checks it against the packet length. The
only validation (skb->len < ETH_HLEN + 8 + sizeof(struct rxpd))
bounds the total length, not pkt_ptr.
A bogus device can report an arbitrary pkt_ptr:
- the memcmp() against the RFC1042 header reads 6 bytes at
pkt_ptr + 14, potentially past the skb buffer
- if the compared bytes happen to match, the EthernetII header
reconstruction writes 12 bytes at pkt_ptr + 8;
- hdrchop derived from pkt_ptr is later passed to skb_pull().
Validate pkt_ptr before using it: it must leave room for a full
struct rxpackethdr within the received frame. It is not expected
to affect the driver behavior in most cases, only invalid pkt_ptr
packets being dropped.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Assisted-by: LLM
Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
Link: https://patch.msgid.link/f22d4f23e5e54b1debd6038b3b75119f97920a73@linux.dev
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If our .suspend() fails, we forget to unwind the early steps -- namely,
re-attaching our network interfaces. This commonly occurs if, for
example, we fail to program WoWLAN patterns to the device. Without this,
the interface won't work again.
Tested on a Rockchip RK3399 Gru/Kevin Chromebook, with Marvell 8997
PCIe WLAN.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20260925172218.1.Ie4146d413a6be79caa11cf34e19b23f514ad3f5e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
I came across a rare warning in the b43legacy driver while building
randconfig kernels using clang-21.1.8, with KASAN enabled:
drivers/net/wireless/broadcom/b43legacy/main.c:3250:12: error: stack frame size (1392) exceeds limit (1280) in 'b43legacy_wireless_core_init' [-Werror,-Wframe-larger-than]
3250 | static int b43legacy_wireless_core_init(struct b43legacy_wldev *dev)
| ^
There are no actual large variables on the stack here, just excessive
spills, and the code looks fine otherwise, so this is really an
optimization quirk in the compiler. Marking the prepare_phy_data_for_init()
function as noinline completely avoids the issue, with no function in
this file using more than 200 bytes of stack space, same as without KASAN.
Link: https://pastebin.com/raw/KpV124Ep # .config
Link: https://pastebin.com/CxWfsBN0 # assembler output, truncated
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260925130749.4191347-1-arnd@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cw1200_rx_cb() stores the link ID from the device-supplied WSM
header (a 4-bit field, range 0-15) into priv->action_linkid for P2P
public action frames without an upper bound check. The work handler
cw1200_link_id_reset() then uses it to index link_id_db[], which has
only CW1200_MAX_STA_IN_AP_MODE (5) entries, so a device reporting a
link ID of 6-15 makes the driver read and write cw1200_common fields
past the array (a status copy and a constant store onto adjacent
work/lock/timer fields), corrupting driver state.
The first link ID check in the same function (used for timestamp
tracking) already validates against CW1200_MAX_STA_IN_AP_MODE and
degrades out-of-range IDs to untracked handling, so out-of-range
link IDs on the RX path are anticipated; the P2P remap branch was
missed.
Add the same bound to the remap branch. This is expected to keep
driver behavior unchanged in most cases: the driver itself only
assigns link IDs 1..5, and a P2P public action frame carrying any
other ID now degrades to the same untracked handling the first
branch already applies, instead of corrupting memory.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Assisted-by: LLM
Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
Link: https://patch.msgid.link/969ee752d023e7431481605c320fa0636cc6f20c@linux.dev
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mwifiex_sdio_fw_dump() reads the number of memory regions (dump_num)
from a device register and uses it to index the static 15-entry
mem_type_mapping_tbl[] without any bounds check. A bogus device can
report a dump_num larger than the table; each out-of-table loop
iteration then reads entry->mem_name and entry->done_flag and stores
a vmalloc pointer and a device-controlled size past the end of the
table, into adjacent .data (up to ~5.6KiB when dump_num is 255).
The dump path runs after command timeouts or firmware crashes, so a
bogus device can first force an error to trigger the dump and then
report a bogus dump_num.
Limit dump_num to the table size instead of aborting the dump. This
is not expected to change the behavior on normal devices.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Assisted-by: LLM
Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/33a45fd59b5569cbce79142d2e012e191989ec26@linux.dev
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>
Simulate firmware completing a deferred NAN schedule update in
mac80211_hwsim by calling ieee80211_nan_sched_update_done() from a delayed
work, so that the completion notification reaches user space after the
update request returns, as it would with real hardware. This doesn't really
implement the schedule update flow and doesn't announce anything to the
peers. However, it should be good enough meanwhile for some minimal testing.
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/20260922144356.81f62b390ef6.I21654fe82a0065a055a1b958297b2beb4337a1f0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When IEEE80211_PROBE_FLAG_MIN_CONTENT is set, restrict the probe
request supported rates per Draft P802.11bi D5.0 specification:
- 2 GHz: only include 1, 2, 5.5, 6, 11, 12, 24 Mb/s
- 5/6 GHz: only include 6, 12, 24 Mb/s
Also skip the Extended Supported Rates element for minimal
content probes.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Assisted-by: GitHub-Copilot:claude-opus-4-6
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260922143146.13a6fab60516.I3ebb1fa5d41622b1a0ddf9d008328fc19ad980a1@changeid
[drop strange comment about extended element]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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>
My static analyzer identified a potential issue in 'net/mac80211/mesh_pathtbl.c':
mpath_expired() reads mpath->flags and mpath->exp_time without holding
mpath->state_lock, while mesh_path_fix_nexthop() and the other writers update
both fields under that lock. In mpath_lookup() and
__mesh_path_lookup_by_idx() the unlocked check is followed by taking the lock
and clearing MESH_PATH_ACTIVE, so the check and the update are not atomic:
CPU0 (mpath_lookup) CPU1 (mesh_path_fix_nexthop)
mpath_expired() reads the stale
flags/exp_time and returns true
spin_lock_bh(&mpath->state_lock)
mpath->exp_time = 0;
mpath->flags = FIXED|SN_VALID;
mesh_path_activate(mpath);
spin_unlock_bh(&mpath->state_lock)
spin_lock_bh(&mpath->state_lock)
mpath->flags &= ~MESH_PATH_ACTIVE;
spin_unlock_bh(&mpath->state_lock)
A path which mesh_path_fix_nexthop() has just set up as MESH_PATH_FIXED and
MESH_PATH_ACTIVE then has MESH_PATH_ACTIVE cleared again, and forwarding to
that destination silently stops.
Take mpath->state_lock before evaluating mpath_expired() so that the check and
the clearing of MESH_PATH_ACTIVE are atomic with respect to the writers.
Fixes: 60854fd945 ("mac80211: mesh: convert path table to rhashtable")
Signed-off-by: Ginger Li <ginger.jzllee@gmail.com>
Link: https://patch.msgid.link/20260922054253.11976-1-ginger.jzllee@gmail.com
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>
Implement the nan_set_non_evac_channels operation in mac80211. It marks
the provided channels as non-evacuable in the current local schedule and
clears the flag on all other channels. All provided channels must exist
in the current schedule, otherwise -ENOENT is returned.
ieee80211_nan_find_evac_chan() skips channels marked as non-evacuable
when selecting a channel to evacuate for concurrent operations.
Fixes: 42c9de58d9 ("wifi: mac80211: add NAN channel evacuation support")
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.ef5884349253.I38b685378c3557679ed6387922a94a7da821555c@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: 154b0296c0 ("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>
Add the handling of CIP during association, when adding a station in AP
mode and also add some checks whether the keys are being installed
correctly.
For internal use, add a new key flag CIP that is used for both the
pairwise key and CIGTK. The CIGTK will then have the MCAST_KEY and CIP
flags set.
As the CIGTK uses key indices 0 and 1, add a new variable to track it
separately from the other GTKs.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260921144048.f032c70e0bc2.I30cf9ae29629188b8674e2268a6b592c1a63128b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The CIGTK keys use a key index of 0 or 1, which is not unique. As such,
a new parameter is needed to differentiate the key type. Add the
parameter to prepare for handling the CIGTK in the future.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260921144048.8bfea7df6b06.I3d046fbe7dfb3883471773f84e7a791b5b97000e@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>
Since there are two sets of key flags, one for the driver
and one internal to mac80211, add the first set in debugfs
as well. This will be used by hwsim tests to determine if
a key is pairwise or not, since the next changes will make
mac80211 use only per-STA GTKs.
Link: https://patch.msgid.link/20260921144048.641cb1492f2e.I3a7d6912def9ba2623b41cc672704cbe3beb0bf3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Conntrack flush supports filtering by zone using CTA_ZONE, but this
attribute is really hard to use from user space applications. The
reason is that it is not possible to tell if it's supported or not.
Older kernels silently ignore CTA_ZONE. And in that case they just
happily flush all the entries from all zones breaking all the existing
connections. So, applications have to infer support from the kernel
version. While it works in most cases, it's not a particularly
reliable or desired way to check kernel capabilities from applications
that aim to be portable. There should be a better way to probe or
discover features in the kernel.
The CTA_FILTER interface on the other hand is simple enough to probe.
We can check for NLM_F_DUMP_FILTERED in the dump to see if filtering
is supported. And unknown sub-attributes in CTA_FILTER are rejected
explicitly since strict validation is in use there.
Let's add new CTA_FILTER_ZONE that signals that CTA_ZONE should be
filtered on. It is a flag, since everything in the CTA_FILTER is a
bit mask, i.e., a form of a flag. If set, it means that CTA_ZONE must
be present and be used for filtering. If the flag is not set however,
the filtering on CTA_ZONE will still take place to ensure backwards
compatibility. So, the flag doesn't really change the filtering
behavior, but it allows user space applications to properly discover
support for CTA_ZONE filtering without need to rely on kernel version
parsing or risk accidental flushes of the entire conntrack table,
and also without modifying the kernel state.
A new test variant is added to test with and without the new flag.
Since the setup code is moved into a shared function, expectations
replaced with assertions to bail early if the base setup fails to
avoid the cascade of secondary failures that can be misleading.
Error return is only for the SKIP cases.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
ctnetlink_filter_match_tuple() rejects an entry when
!ipv6_addr_cmp(filter, entry) is true. ipv6_addr_cmp() is a memcmp() and
returns 0 for equal addresses, so the condition is true exactly when the
addresses match: a CTA_FILTER dump with an IPv6 CTA_IP_SRC or CTA_IP_DST
skips every entry that matches the requested address and returns all the
others. The IPv4 branch compares with != and behaves correctly.
Observed with libnetfilter_conntrack NFCT_FILTER_DUMP_TUPLE: a dump
filtered on src 2001:db8::10 returned only the unrelated entries, and a
dump filtered on ::1 returned every entry except the ::1 ones.
conntrack-tools does not use the tuple filter for -L, which is why this
went unnoticed.
Use ipv6_addr_equal() so the IPv6 branch mirrors the IPv4 one.
Fixes: cb8aa9a3af ("netfilter: ctnetlink: add kernel side filtering for dump")
Cc: stable@vger.kernel.org
Signed-off-by: Piotr Kubik <piotr@kubik.pl>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Handling of concurrent hook changes with a dump in progress was
problematic in nfnl_hook_dump and entirely broken in nfnl_hook_dump_nat.
Address all issues in a single patch to please the review LLM.
Introduce sequence numbers in struct netns_nf to replace pointer
value-based modification detection which may fail due to memory buffer
reuse. This also eliminates the need for most manual cb->seq updates and
excessive array index value checks.
Since nat hook updates are protected by a different mutex than others,
they have to bump their own sequence number. nfnl_hook_dump_nat
therefore open-codes what nl_dump_check_consistent does but bumps
cb->seq instead of setting NLM_F_DUMP_INTR flag.
Dumps of many nat hooks was entirely broken since the array index was
not (re)stored. Use cb->args[1] for that and make sure it is reset upon
completion as the same dump may loop over multiple arrays of nat hooks.
In nfnl_hook_dump, don't signal NLM_F_DUMP_INTR if
nfnl_hook_entries_head returns error: This is a permanent condition
which does not change during a dump. It is already caught by
nfnl_hook_dump_start though, so should not happen anyway.
In general, access ops array pointer values using READ_ONCE since they
are assigned to using WRITE_ONCE.
Avoid setting NLM_F_DUMP_INTR flag in garbage memory by calling
nl_dump_check_consistent only for non-empty skbs. If not a single
netlink message was created, nfnetlink code will take care of setting
the flag.
Fixes: e2cf17d377 ("netfilter: add new hook nfnl subsystem")
Fixes: b010e2a4a9 ("netfilter: nfnetlink_hook: Dump nat type chains")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
