summaryrefslogtreecommitdiff
path: root/include/net
AgeCommit message (Collapse)Author
2026-09-23net: ipv6: keep room for the mac header in dst_dev_overhead()Yuya Kusakabe
The seg6, ioam6 and rpl lwtunnels size their skb_cow_head() request as the length they are about to push plus dst_dev_overhead(), then push the new headers and rebuild the mac header below them with skb_mac_header_rebuild(). That rebuild needs skb->mac_len of headroom, but dst_dev_overhead() leaves LL_RESERVED_SPACE() of the egress device, 16 bytes for plain Ethernet. Where the mac header is longer than that, as it is on ingress through a VLAN device with reorder_hdr off, the rebuild runs out of room: skb_set_mac_header(skb, -skb->mac_len) computes a negative offset, stores it unchecked in the u16 skb->mac_header, and the memmove that follows writes skb->mac_len bytes about 64 KB past skb->head. Forwarding plain ping6 traffic through such a device reproduces it on all five seg6 encapsulation modes and on the rpl and ioam6 inline paths; skb->mac_header comes back as 65534 on a 704-byte head. Return the larger of the two. The helper already returns skb->mac_len when it has no dst, so this only makes the other branch agree, and it covers every caller rather than each call site in turn. Fixes: 40475b63761a ("net: ipv6: seg6_iptunnel: mitigate 2-realloc issue") Fixes: dce525185bc9 ("net: ipv6: ioam6_iptunnel: mitigate 2-realloc issue") Fixes: 985ec6f5e623 ("net: ipv6: rpl_iptunnel: mitigate 2-realloc issue") Suggested-by: Andrea Mayer <andrea.mayer@uniroma2.it> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com> Reviewed-by: Justin Iurman <justin.iurman@gmail.com> Reviewed-by: Gabriel Goller <g.goller@proxmox.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it> Link: https://patch.msgid.link/20260922-seg6-maclen-headroom-v3-1-7b2f982ef79d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-23nfc: fix use-after-free in nfc_get_local_general_bytesLuxiao Xu
Commit 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by nfc_llcp_find_local") attempted to fix a use-after-free (UAF) issue by invoking nfc_llcp_local_put(local) after accessing local->gb. However, if the reference count drops to zero, local is freed immediately, leading to a use-after-free when callers access the returned pointer. Alternative approaches using dynamic allocation (e.g. kmemdup) introduced memory leaks because callers consistently treat the returned pointer as borrowed memory. Fix this properly by refactoring nfc_llcp_general_bytes() and nfc_get_local_general_bytes() to accept a caller-provided output buffer (out_gb) and its maximum length (gb_max_len). The general bytes are safely copied into out_gb before calling nfc_llcp_local_put(local), ensuring safe lifetime management without ownership transfer complications. Update all callers across drivers (microread, pn533, pn544, st21nfca, digital_dep, and nci) to provide their own destination buffers and pass them to nfc_get_local_general_bytes(). Fixes: 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by nfc_llcp_find_local") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Assisted-by: LLM Signed-off-by: Luxiao Xu <rakukuip@gmail.com> Signed-off-by: Ren Wei <weir@nebusec.ai> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/3cbaac3bee23f8ff3a3284ed32d347696eb1d208.1788841683.git.rakukuip@gmail.com Signed-off-by: David Heidelberg <david@ixit.cz>
2026-09-23Bluetooth: hci_core: Fix inquiry cache timestamps on 64-bit systemsLinmao Li
On 64-bit systems, outgoing BR/EDR connections always fall back to page scan repetition mode R2 with no clock offset once the system has been up for more than five minutes, even when inquiry found the peer only seconds earlier. This lengthens paging and can increase the risk of a Page Timeout. The inquiry cache stores jiffies in __u32 timestamps, but its age helpers subtract them from unsigned long jiffies. INITIAL_JIFFIES casts -300 * HZ through unsigned int, so jiffies crosses 2^32 five minutes after boot on 64-bit systems. Assigning it to __u32 then drops the upper 32 bits. In one trace, a 7.6-second-old entry (HZ=1000) was reported as 2^32 + 7620 ticks old and rejected by hci_acl_create_conn_sync(). hci_inquiry() is affected by the same truncation when checking the whole cache. 32-bit systems are unaffected because unsigned long is 32 bits wide there. Use unsigned long for both timestamps so they have the same width as jiffies on 32-bit and 64-bit systems, and update the debugfs format specifier accordingly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-09-21Merge tag 'wireless-next-2026-09-21' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== More changes, including drivers: - brcmfmac: FT/OKC roaming offload - ath12k: IPQ5332 platform infrastructure - cfg80211/mac80211: non-STA TX/RX infrastructure for MLO to fix address translation bugs - the rest is mostly minor cleanups etc. * tag 'wireless-next-2026-09-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (101 commits) dt-bindings: net: wireless: Convert WL1251 to DT schema libertas: mesh: remove unused and undocumented sysfs attribute groups wifi: mac80211: fix multi-link UHR association wifi: nl80211: rename no-ACK bitmap to TID bitmap wifi: radiotap: correct EHT TB U-SIG 1 B20:25 wifi: ieee80211: fix FTM bufferable check wifi: mac80211: allow advertising 20 MHz-only non-AP STA wifi: mac80211: WARN on 40 MHz HT/HE mismatch wifi: mac80211: tests: fix memory leak wifi: mac80211: use assign_bit() where applicable wifi: mac80211: pass error station if non-STA transmit was requested wifi: mac80211: pass station to ieee80211_tx_skb_tid wifi: mac80211: report to cfg80211 when no STA is known for a frame wifi: cfg80211: add attribute for TX/RX denoting there is no station wifi: mac80211: rework RX packet handling wifi: mac80211: refactor RX link_id and station handling wifi: mac80211: change public RX API to use link stations wifi: iwlwifi: use link_sta internally to the driver MAINTAINERS: Replace wireless.wiki.kernel.org links wifi: brcmfmac: log the firmware status when a connect fails ... ==================== Link: https://patch.msgid.link/20260921121635.195723-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-21ipv6: Fix dst leak for uncached routes.Kuniyuki Iwashima
ip6_route_output_flags(), ip6_rt_put_flags(), and ip6_dst_check() detect an uncached route by list_empty(&rt->dst.rt_uncached), which replaced the static DST_NOCACHE flag check in commit a4c2fd7f7891 ("net: remove DST_NOCACHE flag"). When a device is unregistered, rt6_uncached_list_flush_dev() unlinks uncached routes tied to the device from rt6_uncached_list. Previously, they were moved to another list with list_move() (__list_del_entry() + list_add()), and since commit 98aa546af5e4 ("inet: remove (struct uncached_list)->quarantine"), the routes are just unlinked with list_del_init(). If list_del_init() runs concurrently, list_empty() evaluates to true; ip6_route_output_flags() calls dst_hold_safe() incorrectly and ip6_rt_put_flags() skips ip6_rt_put(), leaking dst, and thus dev tied via rt->from as well. The same race is partially fixed by commit 9a6f0c4d5796 ("dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()"). Let's check rt6->dst.rt_uncached_list instead. Note that IPv4 does not have the same issue. Fixes: 98aa546af5e4 ("inet: remove (struct uncached_list)->quarantine") Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn> Reviewed-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260920191558.2990636-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-21wifi: radiotap: correct EHT TB U-SIG 1 B20:25Johannes Berg
The mask here needs to cover six bits, not just five, fix that. Link: https://patch.msgid.link/20260916120406.e4c89f440edb.I8d80bba29ff7e7d642ec603098fb7d30f2db5968@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-19ieee802154: avoid deprecated .ndo_do_ioctl callbackArnd Bergmann
The ieee802154 socket implementation is the last remaining caller of the netdevice ioctl callback. In order to completely remove this, add a custom pointer to the existing wpan_dev specific operations structure. Since that structure is currently only used to wrap the 'create' header operation, adjust the naming slightly to make this more generic. It would be a good idea to adjust the calling conventions and split the get/set operations into separate functions, but that can be a follow-up cleanup. For the moment, I kept the actual changes to a minimum to avoid regressions. Link: https://lore.kernel.org/all/20231011140225.253106-2-arnd@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260915211538.1519815-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-19bpf: tcp: Support parse/len/write header option hooks in bpf_tcp_opsAmery Hung
Add the TCP header option callbacks to the bpf_tcp_ops struct_ops type: parse_hdr - parse the options of an incoming skb on an established connection hdr_opt_len - reserve space in the TCP header for bpf options write_hdr_opt - write the reserved bpf options These mirror the BPF_SOCK_OPS_PARSE_HDR_OPT_CB, _HDR_OPT_LEN_CB and _WRITE_HDR_OPT_CB legacy sockops callbacks, but are exposed as struct_ops members so a program can implement them with normal function signatures and per-member helper sets. The reserved header window is shared between the legacy sockops and bpf_tcp_ops paths. tcp_{syn,synack,established}_options() first run the legacy BPF_SOCK_OPS_HDR_OPT_LEN_CB and then call hdr_opt_len, so both sources accumulate into opts->bpf_opt_len; at write time the legacy options are emitted first and bpf_tcp_ops writes after them. API design bpf_tcp_ops overloads the sock_ops header-option helpers rather than introducing a new API: bpf_reserve_hdr_opt(), bpf_store_hdr_opt() and bpf_load_hdr_opt() are exposed per-member (reserve for hdr_opt_len, store/load for write_hdr_opt, load for parse_hdr) and share the existing kernel option-walking core via _bpf_sock_ops{store,load}hdr_opt(), with the bpf_tcp_ops wrappers synthesizing a temporary bpf_sock_ops_kern from the program ctx. This keeps a port from the legacy BPF_SOCK_OPS*_HDR_OPT_CB callbacks mechanical (same helper calls) and adds no new UAPI helper/kfunc surface. An alternative considered was to drop the option helpers entirely: have hdr_opt_len reserve space purely through its return value, and introduce a dedicated TCP-header-option dynptr used for both reading and writing. That is a cleaner, more self-contained interface, but it is a larger change and does not reuse the legacy helpers, making a port from sockops less mechanical. It can be pursued as a follow-up; the helper-based interface here keeps this series focused on moving the hooks to struct_ops. The hdr_opt_len fast path in tcp_established_options() is gated by cgroup_bpf_enabled(CGROUP_TCP_SOCK_OPS). Note this is a global, per-attach-type static branch: it is enabled whenever any bpf_tcp_ops is attached, even one that does not implement hdr_opt_len or that is attached to a different cgroup. In those cases the block still runs but bpf_tcp_ops_hdr_opt_len() no-ops via the per-member check in the dispatch macro. A per-member/per-cgroup gate could be added later if the extra fast-path work proves measurable. Signed-off-by: Amery Hung <ameryhung@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://patch.msgid.link/20260917200542.3689605-13-ameryhung@gmail.com
2026-09-19bpf: tcp: Support selected sock_ops callbacks as struct_opsAmery Hung
In LSFMMBPF 2025, I have talked about moving the BPF_PROG_TYPE_SOCK_OPS to a struct_ops interface [1]. The BPF_SOCK_OPS_*_CB enum interface has grown over time as new TCP callback points were added. A BPF_PROG_TYPE_SOCK_OPS program now commonly needs a large switch on sock_ops->op, and the shared bpf_sock_ops_kern context has become harder to extend because different callbacks have different locking, argument, skb, and helper requirements. The existing 'union { u32 args[4]; u32 replylong[4]; }' is also not reliable in passing args to bpf prog when there are multiple progs attached to a cgroup. The above has already been solved in struct_ops. Add a TCP-specific struct_ops type, bpf_tcp_ops, and support attaching it to cgroups. This allows each callback have its own func signature and allows the verifier to select kfuncs/helpers based on the specific struct_ops member being implemented. This patch wires up the following existing sock_ops callbacks: - BPF_SOCK_OPS_TIMEOUT_INIT - BPF_SOCK_OPS_RWND_INIT - BPF_SOCK_OPS_RTT_CB - BPF_SOCK_OPS_STATE_CB - BPF_SOCK_OPS_RETRANS_CB - BPF_SOCK_OPS_TCP_CONNECT_CB - BPF_SOCK_OPS_TCP_LISTEN_CB - BPF_SOCK_OPS_RTO_CB - BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB - BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB BASE_RTT is ignored as it is not particularly useful. NEEDS_ECN should be done in bpf-tcp-cc instead. The tstamp ones should be a separate struct_ops (e.g. "bpf_sock_ops") that can work in both TCP and UDP. timeout_init and rwnd_init could have a request_sock pointer. This patch tries a different API and directly passes the request_sock pointer as an arg. Two other approaches were considered before settling on having bpf_get_retval() read the dispatcher's run_ctx via saved_run_ctx. The first was to inherit the retval in the trampoline itself: add a helper in the four __bpf_prog_enter*() paths that, for struct_ops programs, copies the chained value from the caller's run_ctx (now saved_run_ctx) into the program's own run_ctx. It works but puts a per-enter program-type check on the generic trampoline fast path, taxing all fentry/fexit/lsm callers for a cgroup-struct_ops-only feature. The second was to do that same inherit only for the int-returning members via a gen_prologue that emits a hidden kfunc at the start of timeout_init/rwnd_init; this keeps the cost off the generic path and scoped to bpf_tcp_ops, but needs a kfunc + BTF_ID + prologue-emission machinery. The chosen approach avoids both: it touches neither the trampoline nor the program, since saved_run_ctx already points at the dispatcher's run_ctx that carries the value. [1], page 13: https://drive.google.com/file/d/1wjKZth6T0llLJ_ONPAL_6Q_jbxbAjByp/view?usp=sharing Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Amery Hung <ameryhung@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://patch.msgid.link/20260917200542.3689605-12-ameryhung@gmail.com
2026-09-18ip6_gre: Convert ip6gre_net.tunnels[][] to hlist.Kuniyuki Iwashima
struct ip6_tnl has a pointer to the next one. Single linked list requires O(n) iteration for device removal and IPv4 tunnel already uses hlist for its hash table. Let's convert ip6gre_net.tunnels[][] to hlist. Once we convert other users (ip6_tunnel.c, sit.c), we can remove the *next pointer from struct ip6_tnl. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260916230353.367014-3-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-18net: dsa: tag_ks8995: Add the KS8995 tag handlingLinus Walleij
The KS8995 100Mbit switch can do proper DSA per-port tagging with the proper set-up. This adds the code to handle ingress and egress KS8995 tags. The tagger is used by the KSZ8995XA support added later in this series. The tag is a modified 0x8100 ethertype tag where a bit in the last nibble is set for each target port. Always insert a distinct outer switch tag. User ports remove this field on egress, so reusing an existing 802.1Q header would consume the sender VLAN tag instead of preserving it. Push any hardware-accelerated VLAN tag into the packet first. This keeps the switch tag at offset 12 while retaining 802.1Q, 802.1ad and stacked VLAN headers as inner payload, and avoids relying on a valid SKB MAC header in direct transmit paths. Rate-limit receive untagging errors so repeated failures cannot flood the kernel log. Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260916-ks8995-to-ksz8-v15-2-8825ff5fd4be@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-18net: gue: reject invalid REMCSUM offsetsJérémy Jean
The REMCSUM option carries an absolute checksum start and checksum field offset. gue_remcsum() passes them to skb_remcsum_process(), whose partial path stores offset - start in the u16 skb->csum_offset variable. If offset is less than start, this underflows. A forwarded packet can retain CHECKSUM_PARTIAL and reach a NETIF_F_HW_CSUM driver which trusts the metadata, leading skb_copy_and_csum_dev() to write two bytes about 64 KiB beyond the destination buffer. Reject reversed tuples in validate_gue_flags(), after the existing length validation, so all GUE parsers enforce the ordering in one place. Fixes: fe881ef11cf0 ("gue: Use checksum partial with remote checksum offload") Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> Link: https://patch.msgid.link/20260915124806.2852293-2-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-17Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.3-rc4). Conflicts: net/core/neighbour.c 979aabdad8dd0 ("neighbour: Skip default parms when resumed in neightbl_dump_info().") 7b430fcfc972f ("neighbour: Don't render blackhole_netdev via RTM_GETNEIGHTBL.") fae1c59810b86 ("neighbour: Remove unnecessary net_eq().") https://lore.kernel.org/20260911173056.44ec06e0@kernel.org https://lore.kernel.org/aqfbJi7nAX4IbmnR@sirena.co.uk Adjacent changes: net/netlink/af_netlink.c ceac0de741bf ("netlink: do not free nlk->groups while lockless readers can use it") 7c0ec6288b49 ("net: Replace %pK output with 0") net/bridge/br_vlan.c 2842ce397dd0 ("net: bridge: vlan: fix bugs caused by switchdev deletion errors") 5bec8f861114 ("net: bridge: vlan: annotate lockless use of num_vlans") 2b1f8fd3118c ("net: bridge: vlan: annotate lockless vlan flags use") net/bridge/br_mst.c 18a6fe05fb6e ("net: bridge: mst: move switchdev call outside rcu") 120207a08fc0 ("net: bridge: vlan: annotate lockless use of msti") drivers/net/ethernet/stmicro/stmmac/hwif.h 90e4b849dfa6 ("net: stmmac: propagate FPE preemption-class mapping errors") 85ca3292d7a3 ("net: stmmac: Remove ARP offload code") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-16net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()Daniel Zahka
PSP conflicts with TLS ULP in its usage of both skb->decrypted and sk->sk_validate_xmit_skb(). Make PSP mutually exclusive with TLS ULP, the only other user of either of these. As other users of skb->decrypted come along, they can be added to sk_has_decrypt_user(). It would make sense to also assert that sk->sk_validate_xmit_skb() is also NULL in both of these setup paths for similar future proofing, but the PSP listener/sk_clone() path is still broken and it could be seen as a regression to not allow rx assoc to run on a child of a listener socket with PSP tx assoc state. Include all TCP ULPs in the sk_has_decrypt_user() check, even though TLS is the only one that conflicts with PSP via the decrypted bit. This is intentional because PSP was not designed to be used with ULPs. It is best to close off surface area that may make bugs reachable, until someone wishes to design and test an actual user of PSP with ULPs. Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260915-psp-ktls-fix-v2-1-0eedc3b148ec@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-16net/sched: codel: bound the dropping loop per dequeue callJamal Hadi Salim
The CoDel control law schedules the next drop one interval/sqrt(count) after the previous drop, using the configured interval (codel_params.interval). For very small intervals the scheduled step rounds down to zero, so the dropping loop in codel_dequeue() never advances and drains the entire backlog under the qdisc lock in one call - an unprivileged user can trigger a soft lockup this way. Fix in the shared codel code used by both codel and fq_codel: 1. Make the control-law step at least 1 tick so the dropping loop always moves forward. 2. Cap the dropping loop at CODEL_MAX_DROPS_PER_DEQUEUE (256) drops per codel_dequeue() call, resyncing drop_next to now when the cap is hit: the catch-up owed to the loop grows with the idle gap and the backlog, which no interval threshold can bound. This is a deliberate behaviour change after long idle gaps. The cap applies to fq_codel (4b549a2ef4be) and the mac80211 TXQ path (fixed interval, cap only). The target sojourn delay (codel_params.target) is not validated: it does not feed the control law, so a sub-tick value is aggressive rather than deadlock-prone. Conditions to recreate the bug: - tc qdisc add dev lo root handle 1: tbf rate 1kbit burst 2kb limit 1000000 - tc qdisc add dev lo parent 1:1 handle 10: codel interval 2us target 1ms noecn limit 1000000 (same for fq_codel) - unpatched kernel: tc accepts it; a UDP flood under the 1kbit tbf soft-lockups (watchdog: BUG: soft lockup) while one codel_dequeue() call drops the backlog under the qdisc lock - patched kernel: same setup, at most 256 drops per dequeue call, no soft lockup Testing: claim reproducer and interval 2us/3us variants run clean; tdc qdisc category passes (see the selftests patch). Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Reported-by: Vega <vega@nebusec.ai> Reviewed-by: Eric Dumazet <edumazet@google.com> Tested-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/QDISC-1L5H.v1.20260912080102@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-16Merge tag 'wireless-2026-09-16' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Many fixes: - mac80211: S1G TIM bitmap fix - ath12k: remove undocumented DT ABI implementation - various firmware API and over-the-air hardening changes - fixes for most cfg80211/mac80211 syzbot reports * tag 'wireless-2026-09-16' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (67 commits) wifi: brcmsmac: fix UAF in brcms_free_timer() wifi: brcmfmac: fix lost 802.1x TX completion wakeup wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all() wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown wifi: ath12k: ahb: Revert undocumented ABI and dead code wifi: mac80211: refuse to make a monitor active when it has no queue wifi: libipw: reject TKIP frames without a full MIC wifi: virt_wifi: don't transfer operstate before register wifi: cfg80211: check if AP has been started or joined a mesh before adding new station wifi: cfg80211: move link_id validation earlier in nl80211_new_station() wifi: cfg80211: do not support direct add of station to AP_VLAN interfaces wifi: cfg80211: verify if AP_VLAN belongs to the correct AP wifi: mac80211: set up the TX info early to fix failure paths wifi: mac80211: mesh: release the channel if start fails wifi: mac80211: mesh: reset the CSA state when leaving wifi: mac80211: add HE 6 GHz capability in the scan elems len wifi: mac80211: don't access the TSF of a down interface wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set wifi: mac80211: don't allow link changes when iface is down wifi: mac80211: require a peer station for TDLS setup confirm ... ==================== Link: https://patch.msgid.link/20260916083642.110609-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-16wifi: cfg80211: add attribute for TX/RX denoting there is no stationBenjamin Berg
For MLD stations, userspace may need to explicitly transmit a frame to a specific link address. In that case, it needs to ensure that no address translation happens. In the reverse case of an RX, userspace may need to know the link address for a frame. By passing the information whether a STA is known for the frame, userspace knows whether link translation happened and can do the reverse lookup when needed. This is important for flows where a STA is still registered but the connection has been lost and it is returning again. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://patch.msgid.link/20260915151925.f12af80b1972.I4cfd3db83ba3dc0267575f919ba613ea5d10abd5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-16wifi: mac80211: refactor RX link_id and station handlingBenjamin Berg
The link ID for one frequency may be different between VIFs. As such, the sensible thing is to set the link ID later in the flow once the SKB is duplicated for each VIF. As the link ID is not passed in from outside mac80211 it is always valid and the corresponding bit can be dropped. Also switch a few more places to pass the link STA as that is a natural way to pass the link information around. This fixes the per-link statistics when frames are reordered. Note that this patch deliberately leaves some places unchanged and even incorrect as this will be addressed by further refactorings. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://patch.msgid.link/20260915151925.467593bc1105.I8abe3601d0335dca22d48bcee864817cfccf0de0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-16wifi: mac80211: change public RX API to use link stationsBenjamin Berg
If a station is passed then the link ID also needs to be known. As such, it is a more natural API to simply pass the link station directly rather than pushing the link information into the RX status. Furthermore, having the link ID in the RX status is not actually correct because the link IDs are VIF specific and there may be multiple VIFs. In the case of a station this relationship is clear, but then one may as well use the link station. This patch only changes the API and emulates the old (incorrect) behaviour for now. The mac80211 RX code will be updated in later patches. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://patch.msgid.link/20260915151925.06f41565116a.I4a2d45609e94b52654b10ec572e59a45d09c41f4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-15net: mana: Use the HWC destination queues reported by the hardwareManish Awasthi
The hardware provides valid HWC destination vRQ and vRCQ IDs for all PFs and VFs. Use these IDs unconditionally in mana_hwc_send_request(), as the PF-specific gate is not required. Signed-off-by: Manish Awasthi <mawasthi@linux.microsoft.com> Reviewed-by: Long Li <longli@microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/20260910014427.54272-1-mawasthi@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-15page_pool: Fix page_pool_alloc_va() reference in kernel-docKarl Mehltretter
The kernel-doc comment of page_pool_free_va() refers to page_pool_allo_va, which does not exist. The name is page_pool_alloc_va. Say page_pool_alloc_va. The wrong name came in with commit 8ab32fa1c794 ("page_pool: update document about fragment API"). Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://patch.msgid.link/20260912060019.39902-1-kmehltretter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-15Bluetooth: coredump: Quiesce dump work on unregisterWeiming Shi
hci_devcd_handle_pkt_init() arms dump_timeout and coredump producers queue dump_rx without holding an hdev reference. Unregister leaves both works live, so disconnecting during an active dump lets them access hdev after hci_release_dev() frees it. Shut down coredump processing during unregister. Close the producer gate under dump_q.lock before disabling both works, then free the active buffer and queued packets under hci_dev_lock. Serializing the gate with enqueue prevents controller-specific workers from adding packets after the final purge. Fixes: 9695ef876fd1 ("Bluetooth: Add support for hci devcoredump") Reported-by: syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b170dbf55520ebf5969a Reported-by: Aby Sam Ross <abysamross@gmail.com> Link: https://lore.kernel.org/r/20260322210849.68743-1-abysamross@gmail.com Suggested-by: Aby Sam Ross <abysamross@gmail.com> Reported-by: Tristan Madani <tristan@talencesecurity.com> Link: https://lore.kernel.org/r/20260814231248.3096377-1-tristmd@gmail.com Reported-by: Xiang Mei <xmei5@asu.edu> Assisted-by: OpenAI Codex:gpt-5 Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-09-15ip_tunnel: Protect ip_tunnel_net.tunnels[] with mutex.Kuniyuki Iwashima
struct ip_tunnel.net is the netns where encapsulated packets flow into. struct ip_tunnel is linked to ip_tunnel_net.tunnels[] of netns. During netns dismantle or module unload, ip_tunnel_delete_net() iterates the list and queues devices for destruction regardless of the devices' netns. Thus, once RTNL is removed, the list can be modified concurrently from different netns due to device removal. Let's protect it with per-netns mutex. Note that dev_siocdevprivate() calls netdev_lock_ops() but it must be NOP for tunnel devices to avoid AB-BA deadlock. DEBUG_NET_WARN_ON_ONCE() is added to annotate the locking explicitly. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260912230043.2586313-7-kuniyu@google.com Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-09-15ip_tunnel: Don't pass rtnl_link_ops to ip_tunnel_delete_net().Kuniyuki Iwashima
ip_tunnel_delete_net() no longer uses the 3rd argument, struct rtnl_link_ops *ops. Let's remove it. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260912230043.2586313-4-kuniyu@google.com Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-09-14wifi: radiotap: add S1G TLVs and channel frequencyLachlan Hodges
Add the necessary definitions to create radiotap S1G TLVs and channel flags for S1G sniffers. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20260909073014.53344-2-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-11net: dropreason: add SKB_DROP_REASON_IP_TTL_EXCEEDEDJunjie Cao
The forwarding paths report an expired TTL or hop limit as SKB_DROP_REASON_IP_INHDR, the reason otherwise used for a header that is malformed (ip_input.c, exthdrs.c, br_netfilter). Nothing else in the drop path separates the two: IPSTATS_MIB_INHDRERRORS covers both, and the TTL check runs before NF_INET_FORWARD, so netfilter tracing stops at PREROUTING and never sees the drop. The Fedora bug linked below shows how that reads in practice. The reporter took kfree_skb(reason=IP_INHDR, loc=ip_forward) to mean the software header checksum check had failed, and worked through RX checksum offload, tc csum actions and both libvirt firewall backends before the drops turned out to be replies arriving with TTL 1. ip_forward() never verifies the header checksum; that runs earlier, in ip_rcv_core(), and reports IP_CSUM. TTL expiry is not a corner case -- every traceroute through a Linux router goes through too_many_hops. The three loopback hop limit checks in exthdrs.c drop with no reason at all; give them the new one. IPSTATS_MIB_INHDRERRORS stays as it is: RFC 1213 counts time-to-live exceeded under ipInHdrErrors. The drop reason has no such constraint. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2517131 Signed-off-by: Junjie Cao <junjie.cao@intel.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn> Link: https://patch.msgid.link/20260910094937.536150-1-junjie.cao@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-10sit: convert configuration to RCU protectionEric Dumazet
Now that SIT parameters are dynamically allocated, convert tunnel->sit_parms to an RCU-protected pointer. Updates in ipip6_tunnel_update() allocate a new parameter block, publish it using rcu_assign_pointer(), and free the old one via kfree_rcu(). We only need to unlink and re-link the tunnel in the hash table if either saddr or daddr changed. When neither address changes, the unhash/re-hash and synchronize_net() can be completely skipped. Readers in ipip6_tunnel_lookup(), ipip6_tunnel_xmit(), ipip6_err(), and ipip6_rcv() now safely dereference tunnel->sit_parms under RCU. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> Link: https://patch.msgid.link/20260907075846.2913645-9-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-10sit: dynamically allocate struct ip_tunnel_parm_kernEric Dumazet
In preparation for converting SIT configuration parameters to RCU, dynamically allocate struct ip_tunnel_parm_kern as sit_parms in struct ip_tunnel. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> Link: https://patch.msgid.link/20260907075846.2913645-8-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-10sit: convert 6RD configuration to RCU protectionEric Dumazet
In order to allow lockless readers in future patches, convert 'tunnel->ip6rd' to an RCU protected pointer. Updating 6RD configuration via ipip6_tunnel_update_6rd() or ipip6_tunnel_clone_6rd() now allocates a struct ip_tunnel_6rd_parm and uses rcu_assign_pointer() to publish it, freeing the previous parameters with kfree_rcu(). Readers in check_6rd() and only_dnatted() use rcu_dereference() under existing RCU read lock, preventing torn reads on the 128-bit IPv6 prefix. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> Link: https://patch.msgid.link/20260907075846.2913645-6-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.3-rc3). Conflicts: drivers/net/dsa/mt7530.c 3c18e3c9a54e ("net: dsa: mt7530: populate lpi_interfaces to fix EEE support") 10d9d8328e8a ("net: dsa: mt7530: replace mt7530_read with regmap_read") Adjacent changes: drivers/net/bonding/bond_alb.c 1746ef2e2df2 ("bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()") 4cef95f72bbd ("bonding: fix u32 overflow in compute_gap()") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-09wifi: mac80211: don't allow injecting frames wider than the chanctxJohannes Berg
Frames injected on a monitor interface can carry a radiotap field requesting a bandwidth, which mac80211 passes down to the driver regardless of the the actual operational bandwidth. If the bandwidth requested is too wide, that triggers a warning in hwsim: WARN_ON(hwsim_get_chanwidth(bw) > hwsim_get_chanwidth(confbw)) Drop such frames entirely instead since they cannot be sent. Assisted-by: LLM Fixes: 646e76bb5daf ("mac80211: parse VHT info in injected frames") Reported-by: syzbot+435fdb053cf98bfa5778@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=435fdb053cf98bfa5778 Link: https://patch.msgid.link/20260908122838.201719-13-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-07tcp: Do not allow buggy transitions between ehash and lhash2.Kuniyuki Iwashima
The following state transitions have long been a playground for syzbot, and recently AI joined in, reporting a lot more bugs. * listen() + shutdown() + connect() * connect() + connect(AF_UNSPEC) + listen() All the fix attempts would add more code to the fast path, which is not worth it. Instead of playing whack-a-mole with these edge-case bugs, let's disallow these transitions. Note that unhashed_state is placed in the 4-byte hole after icsk_pmtu_cookie. $ pahole -C inet_connection_sock vmlinux struct inet_connection_sock { ... __u32 icsk_pmtu_cookie; /* 1208 4 */ unsigned char unhashed_state; /* 1212 1 */ /* XXX 3 bytes hole, try to pack */ Reported-by: Kyle Zeng <kylebot@openai.com> Closes: https://lore.kernel.org/netdev/20260731140512.566464-1-david.lee@trailofbits.com/ Reported-by: Michal Luczaj <mhal@rbox.co> Closes: https://lore.kernel.org/netdev/20260803-sockmap-lookup-tcp-leak-v2-0-306e025bfe66@rbox.co/ Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Closes: https://lore.kernel.org/netdev/20260824033331.1084971-1-imv4bel@gmail.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260904033543.2635540-2-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-07net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forwardAlice Mikityanska
Commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") dropped the IP6_MAX_MTU clamp that used to be present in ip6_mtu(). A similar IPv4 commit ac6627a28dbf ("net: ipv4: Consolidate ipv4_mtu and ip_dst_mtu_maybe_forward") preserves the IP_MAX_MTU clamp. Restore the upper bound in the IPv6 flow to avoid potential 16-bit overflows in forwarding paths. Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") Signed-off-by: Alice Mikityanska <alice@isovalent.com> Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260901195714.673548-5-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-07netdevsim: psp: drop tx key opsDaniel Zahka
netdevsim has no SADB. The usage of psp_assoc_drv_data() was always obsolete given psp_validate_xmit(), so we can remove nsim_assoc_add() and nsim_assoc_del(). netdevsim::assoc_cnt can also be removed. PSP core can track the balance of tx_key_add vs tx_key_del calls in a future change. Delete psp_assoc_drv_data() because there are no more callers left in the tree. mlx5 accesses pas->drv_data directly. Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20260903-psp-prep-v1-4-d47e9c4c375d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-07psp: allow drivers to omit tx key add/del opsDaniel Zahka
Drivers that don't use an SADB for tx key storage don't have a use for psp_dev_ops::tx_key_add and psp_dev_ops::tx_key_del. Allowing drivers to leave these as NULL gives PSP core a simple way to determine whether a driver utilizes an SADB, which in turn could affect how PSP core chooses to handle certain situations. For example: - deciding if tx key deletion needs to be delayed during a rekeying event to avoid in-flight packets using old key handles. - choosing whether or not to report device stats like SADB usage to userspace, which only make sense if the driver uses on-device key storage. Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20260903-psp-prep-v1-3-d47e9c4c375d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-05net/sched: defer qdisc freeing after failed creationWeiming Shi
An RTM_NEWQDISC request can make clsact bind a populated shared ingress block during ->init(), publishing an embedded mini_Qdisc to lockless readers. If the same request has an invalid TCA_RATE, estimator setup fails after ->init(); the unwind removes the pointer but synchronously frees its containing qdisc while tc_run() may still hold it. Retire failed qdiscs through the same RCU helper as normal destruction. Inline the synchronous free into the callback now that no direct callers remain. Fixes: 51ab2994c387 ("net: sched: allow ingress and clsact qdiscs to share filter blocks") Reported-by: Xiang Mei <xmei5@asu.edu> Link: https://lore.kernel.org/netdev/20260805102505.740806-1-david.lee@trailofbits.com/ Signed-off-by: Weiming Shi <bestswngs@gmail.com> Link: https://patch.msgid.link/20260902155231.2149915-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-05tcp: Replace min_tso_segs() with tso_segs() CC callbackChia-Yu Chang
This patch replaces the existing min_tso_segs() callback with a new tso_segs() callback, allowing congestion control algorithms to provide an explicit TSO segment count for each data burst and bypass tcp_tso_autosize(). The resulting tso_segs value is clamped to [1, sk->sk_gso_max_segs], preventing congestion-control implementations from returning an invalid zero-segment value. This change has the following impacts on BPF struct_ops users: - The callback is renamed from min_tso_segs() to tso_segs() - The signature gains an extra u32 mss_now argument - The return value semantics is changed from "floor value passed into tcp_tso_autosize()" to "final tso_segs value", bypassing autosizing As a result, existing BPF programs must be updated, because returning a small constant will now directly limit the final tso_segs value instead of specifying the minimum value passed to tcp_tso_autosize(). Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com> Signed-off-by: Ilpo Järvinen <ij@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04neighbour: Don't store net in struct pneigh_entry.Kuniyuki Iwashima
neigh_table is now per-netns, so struct pneigh_entry does not need to store a net pointer. Let's remove it and net comparison for pneigh_entry. We no longer need to pass net to pneigh_create(), pneigh_delete(), and pneigh_lookup(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260902203722.926528-14-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04neighbour: Namespacify neigh_tables.Kuniyuki Iwashima
Now, neigh_table is ready to be namespacified. Let's allocate per-netns neigh_table in neigh_table_register() and call neigh_table_init() and neigh_sysctl_register() for it. proc_create_seq_data() is changed to proc_create_net_data(). Since each netns has its own sysctl knobs, RTM_SETNEIGHTBL can configure the default table param (ifindex==0) and GC parameters per netns. To avoid potential regression, all the default parameters under /proc/sys/net/ipv{4,6}/neigh/default/, are inherited from init_net by default. This behaviour is controlled by a new sysctl knob, net.core.neigh_inherit_init_net: # sysctl net.core.neigh_inherit_init_net net.core.neigh_inherit_init_net = 1 # sysctl net.ipv4.neigh.default.gc_thresh1 net.ipv4.neigh.default.gc_thresh1 = 128 # sysctl net.ipv4.neigh.default.gc_thresh1=129 net.ipv4.neigh.default.gc_thresh1 = 129 # unshare -n sysctl net.ipv4.neigh.default.gc_thresh1 net.ipv4.neigh.default.gc_thresh1 = 129 If it is turned off, all settings are reset in the new netns: # sysctl net.core.neigh_inherit_init_net=0 net.core.neigh_inherit_init_net = 0 # unshare -n sysctl net.ipv4.neigh.default.gc_thresh1 net.ipv4.neigh.default.gc_thresh1 = 128 The next patch will remove other unnecessary net_eq(). Note that CONFIG_SYSCTL cannot be enabled without CONFIG_PROC_FS. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260902203722.926528-13-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04neighbour: Convert neigh_table.entries to refcount_t.Kuniyuki Iwashima
We will allocate neigh_table for each netns and free it when netns is destroyed. neigh_ifdown() cleans up all neighbour entries during netns dismantle, but there is no synchronisation between timers because neigh_del_timer() uses timer_delete() to stop a timer. If neigh_table were freed while timer were running, neigh_destroy() would touch the freed table. If we called timer_delete_sync() in neigh_flush_one() under tbl->lock, lockdep would complain although it is false-positive. Let's convert neigh_table.entries to refcount_t and destruct neigh_table only when the count reaches 0. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260902203722.926528-12-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04ipv6: Replace &nd_tbl with nd_table(net).Kuniyuki Iwashima
We will allocate per-netns neigh_table in net->neigh_tables[]. Let's replace &nd_tbl with nd_table(net). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260902203722.926528-10-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04ipv4: Replace &arp_tbl with arp_table(net).Kuniyuki Iwashima
We will allocate per-netns neigh_table in net->neigh_tables[]. Let's replace &arp_tbl with arp_table(net) and remove extern definition for arp_tbl. Three notes: 1. mlx5e_rep_netevent_event() and nfp_tun_neigh_event_handler() have code assuming neigh_table other than &arp_tbl and &nb_tbl, and the part is removed as it will be false once per-netns table is allocated. 2. prestera and rocker uses init_net because they set dev->netns_immutable to true. 3. mlx5e_tc_update_neigh_used_value() dereferences nhe->neigh_dev in trace_mlx5e_tc_update_neigh_used_value(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260902203722.926528-9-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04neighbour: Remove neigh_tables[].Kuniyuki Iwashima
Now, &arp_tbl and &nd_tbl are stored in net->neigh_tables[]. Let's use net->neigh_tables[] in neighbour.c and remove the global neigh_tables[]. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260902203722.926528-8-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04neighbour: Store arp_tbl and nd_tbl in net->neigh_tables[].Kuniyuki Iwashima
We will remove RTNL for neigh_add() and neigh_delete(), but they are still serialised by per-protocol neigh_table.lock. We can avoid contention by converting neigh_tables[] to per-netns, but arp_tbl and nd_tbl are directly used in many places. As a prep, let's store &arp_tbl and &nd_tbl in net->neigh_tables[]. We will replace such users with arp_table(net) and nd_table(net) and then allocate per-netns neigh_table. Note that nd_table() still returns &nd_tbl in case disable_ipv6_mod is 1 because some buggy drivers use nd_tbl without checking it. proc_create_net() is guarded with CONFIG_PROC_FS because it returns NULL when =n and setup_net() fails and panic()s. Also a later patch moves neigh_sysctl_register() under the guard. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260902203722.926528-7-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04neighbour: Remove __neigh_for_each_release().Kuniyuki Iwashima
Since commit 6deb53595092 ("net: remove unused ATM protocols and legacy ATM device drivers"), there is no in-kernel user of __neigh_for_each_release(). Let's remove it. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260902203722.926528-3-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04r8169: add support for RTL8127atfJaven Xu
RTL8127atf is also a fiber mode card, but its sds reg base addr is 0x0080, which is different from RTL8116af. Add 10g and 1g support for RTL8127atf in this patch. Signed-off-by: Javen Xu <javen_xu@realsil.com.cn> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260831053745.1197-6-javen_xu@realsil.com.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-04wifi: mac80211: avoid trimming injected FCS twiceMariano Baragiola
When packet sockets use PACKET_QDISC_BYPASS, mac80211 can parse the radiotap header while selecting the queue and again before transmit. If the header includes an FCS, both parses trim the skb. Validate the FCS on both parses, but trim it only before transmit. This keeps queue selection read-only and avoids trimming shared skb data twice. Fixes: cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue") Signed-off-by: Mariano Baragiola <mbaragiola@linux.com> Link: https://patch.msgid.link/20260817233521.2747027-1-mbaragiola@linux.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: nl80211: add support to configure 6 GHz non-HT duplicate transmissionManish Dharanenthiran
As per IEEE Std 802.11-2024, subclause 26.17.2.2, a 6 GHz AP can transmit a Beacon frame using a non-HT duplicate PPDU, so that stations scanning only PSC channels can discover it. Currently, there is no mechanism to request the driver to transmit non-HT duplicate Beacon frames. In [1], changes were made to parse the Beacon from user-space to set the non-HT duplicate flag in the kernel. However, it was suggested that non-HT transmission be part of the Beacon TX rate settings. Hence, add NL80211_TXRATE_6GHZ_NON_HT_DUP as a flag attribute under NL80211_ATTR_TX_RATES to let user-space request the driver to transmit non-HT duplicate Beacons. Also add validation to reject the Beacon if non-HT duplicate Beacon transmission is enabled when legacy rates are not configured. [1] https://lore.kernel.org/all/1644914581-21682-1-git-send-email-quic_ramess@quicinc.com/ Signed-off-by: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com> Link: https://patch.msgid.link/20260805-dup-beacon-v1-1-68574869c896@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: make ieee80211_is_tx_data() internalJohannes Berg
This function isn't used by any driver, and we may want to change it in the future. Don't expose it. Drivers may still do the same determination based on the flags, but if we'd ever change the encapsulation internally etc. (which I'm considering) then the use in mac80211 may need to change, or the function itself. Link: https://patch.msgid.link/20260803135248.cd23ccac65d7.I1c238c6abe39f5a1ff1b11d8556599d01dd03ff0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: mac80211: remove ieee80211_sta_ps_transition() return valueJohannes Berg
Nothing cares, so no point calculating it. Also simplify the "no need to do anything" check and fix some docs that should refer to this function instead. Link: https://patch.msgid.link/20260802211819.1738465-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>