summaryrefslogtreecommitdiff
path: root/net
AgeCommit message (Collapse)Author
2026-07-22net: hsr: fix memory leak on slave unregistration by removing synced VLANsEric Dumazet
When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers. Fixes: 1a8a63a5305e ("net: hsr: Add VLAN CTAG filter support") Reported-by: syzbot+456957213f32970c0762@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a4cb6ca.57639fcc.86d58.000b.GAE@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Reviewed-by: Felix Maurer <fmaurer@redhat.com> Link: https://patch.msgid.link/20260721101240.995597-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-22net: bridge: vlan: fix vlan range dumps starting with pvidNikolay Aleksandrov
There is a bug in all range dumps that rely on br_vlan_can_enter_range() when the PVID is a range starting VLAN, all following VLANs that match its flags can enter the range, but when the range is filled in only the PVID VLAN is dumped and the rest of the range is discarded because br_vlan_fill_vids() checks for the PVID flag. Since the PVID VLAN can be only one, we need to break ranges around it, the best way to do that consistently for all is to alter br_vlan_can_enter_range() to take into account the PVID and return false to break the range when it's matched. Before the fix: $ ip l add br0 type bridge vlan_filtering 1 $ ip l add dumdum type dummy $ ip l set dumdum master br0 $ ip l set br0 up $ ip l set dumdum up $ bridge vlan add dev dumdum vid 1 pvid untagged master $ bridge vlan add dev dumdum vid 2 untagged master $ bridge vlan show dev dumdum # use legacy dump to show all vlans port vlan-id dumdum 1 PVID Egress Untagged 2 Egress Untagged $ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN) port vlan-id dumdum 1 PVID Egress Untagged state forwarding mcast_router 1 VLAN 2 is missing, and if there are more matching VLANs afterwards they'd be missing too. After the fix: [ same setup steps ] $ bridge vlan show dev dumdum port vlan-id dumdum 1 PVID Egress Untagged 2 Egress Untagged $ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN) port vlan-id dumdum 1 PVID Egress Untagged state forwarding mcast_router 1 2 Egress Untagged state forwarding mcast_router 1 Fixes: 0ab558795184 ("net: bridge: vlan: add rtm range support") Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260721140922.682265-2-razor@blackwall.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-22Merge tag 'for-net-2026-07-21' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_sync: Protect UUID list traversal - RFCOMM: Fix session UAF in set_termios - btusb: validate Realtek vendor event length * tag 'for-net-2026-07-21' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: btusb: validate Realtek vendor event length Bluetooth: RFCOMM: Fix session UAF in set_termios Bluetooth: hci_sync: Protect UUID list traversal ==================== Link: https://patch.msgid.link/20260721160240.884274-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-22Merge tag 'wireless-2026-07-22' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Lots of fixes: - mostly driver security/robustness/warning fixes - ath12k: fix MLO throughput regression - iwlwifi: add UNII-9 to avoid regression - brcmfmac: - fix 802.1X-SHA256 - SDIO fix for some boards - mac80211: - fix traffic indication for sleeping STAs - fix NAN throughput * tag 'wireless-2026-07-22' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (80 commits) wifi: brcmfmac: fix 802.1X-SHA256 call trace warning wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() wifi: mt76: mt7925: fix crash in reset link replay wifi: mt76: fix airoha_npu dependency tracking wifi: mt76: restrict NPU/PPE active checks to MMIO devices wifi: mt76: fix MAC address for non OF pcie cards wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() wifi: mt76: mt7915: guard HE capability lookups wifi: mt76: mt7925: guard link STA in decap offload wifi: mt76: Disable napi when removing device wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses wifi: brcmfmac: set F2 blocksize to 256 for BCM43752 wifi: cfg80211: guard optional PMSR nominal time wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO wifi: brcmfmac: drain bus_reset work on device removal wifi: brcmfmac: make release_scratchbuffers idempotent ... ==================== Link: https://patch.msgid.link/20260722092647.119094-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-22seg6: add FIB table attribute for post-encap SID route lookupAndrea Mayer
After SRv6 encapsulation the kernel looks up the route for the first SID, that is the outer IPv6 destination of the encapsulated packet. This post-encap SID route lookup uses the FIB table of the current routing context. When the encap route is installed in a VRF, the VRF's table may not have a route matching the SID. In that case another table should handle it, e.g. one configured for underlay connectivity. Add an optional SEG6_IPTUNNEL_TABLE attribute that selects the FIB table used for this lookup. When set by the user, the attribute is honored on both the input path (forwarded traffic) and the output path (locally originated traffic). SRv6 encap routes that do not set the attribute use the current routing context, as before. For example: # SID route installed in the underlay table 500 ip -6 route add fc00::100/128 via fd00::1 dev veth0 table 500 # encap route in vrf-100; the first SID is looked up in table 500 ip -6 route add cafe::1/128 vrf vrf-100 \ encap seg6 mode encap segs fc00::100 lookup 500 dev veth0 # or look up the SID in the main table ip -6 route add cafe::1/128 vrf vrf-100 \ encap seg6 mode encap segs fc00::100 lookup main dev veth0 Suggested-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260711162907.6521-2-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-22wifi: cfg80211: reg: add a newline in DFS debug messageJiajia Liu
Add a missing newline in the debug message in print_regdomain. Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn> Link: https://patch.msgid.link/20260722071819.22465-1-liujiajia@kylinos.cn [break long line] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-22wifi: cfg80211: tests: check BSS lookup failure reasonsLouis Kotze
Add a KUnit test for the extack failure reasons that __cfg80211_get_bss() now reports: no matching scan entry at all, a matching entry that is expired, and a matching entry whose use_for flags do not allow the requested use. Also cover the cases that must not report a failure (a fresh entry, and an expired-but-held entry), an entry that is both expired and unusable, and the combined message when one matching entry is expired while another is current but unusable. Signed-off-by: Louis Kotze <loukot@gmail.com> Link: https://patch.msgid.link/20260722070734.3612581-3-loukot@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-22wifi: cfg80211: say why the auth/assoc BSS lookup failedLouis Kotze
The BSS lookup for an authentication or association request can fail for three distinct reasons: cfg80211 has no scan entry at all for the BSSID/channel, an entry exists but is older than IEEE80211_SCAN_RESULT_EXPIRE (and not held), or a fresh entry exists but its use_for flags do not allow this use. All three currently surface as the same generic extack message "Error fetching BSS for link" on the MLO association path, and as a bare -ENOENT with no message at all on the authentication and non-MLO association paths. Since wpa_supplicant logs the extack message verbatim ("nl80211: kernel reports: ..."), that message is often the only diagnostic a user sees when an MLO association degrades to fewer links, and it does not say whether a fresh scan could have helped. In practice the expired case is common for MLO partner links: 6 GHz is passive-scan in many regulatory domains, so the partner-link entry is routinely stale by the time userspace requests the association even though the link is perfectly usable. Let __cfg80211_get_bss() take an optional extack and record, during the same bss_lock walk that fails the lookup, whether any matching entry was rejected for being expired or for not being usable for the requested use, and set a distinct message for each case (and a combined one when different entries were rejected for different reasons). Reorder the checks in the walk so that an entry's identity (type, privacy, channel, BSSID/SSID) is established before the usability checks; this doesn't change which entry is returned since an entry is only used when all checks pass. Also give the -EINVAL paths in nl80211_assoc_bss() proper messages while at it, and keep pointing the bad_attr at the failing link on the MLO path there; the message for that case is already set by the lookup itself. Signed-off-by: Louis Kotze <loukot@gmail.com> Link: https://patch.msgid.link/20260722070734.3612581-2-loukot@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-22wifi: mac80211: implement STA-mode peer probingPriyansha Tiwari
Add STA/P2P-client support to ieee80211_probe_peer(): when called for a station interface, send a null-data frame (TODS) to the associated AP and report the ACK via cfg80211_probe_status(). For MLO connections the driver/firmware selects the link (IEEE80211_LINK_UNSPECIFIED); for non-MLO the single link is used. Signed-off-by: Priyansha Tiwari <priyansha.tiwari@oss.qualcomm.com> Link: https://patch.msgid.link/20260709114228.672317-2-pritiwa@qti.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-22Merge branch 'big-tcp-for-udp-tunnels'Paolo Abeni
Alice Mikityanska says: ==================== BIG TCP for UDP tunnels This series is a follow-up to "BIG TCP without HBH in IPv6", and it adds support for BIG TCP IPv4/IPv6 workloads in vxlan and geneve. Now that IPv6 BIG TCP doesn't require stripping the HBH in all various combinations in tunneled traffic, adding BIG TCP becomes feasible. Patch 01 adds accessors for the length field in the UDP header, as suggested by Paolo in review. The usage of udp_set_len is then added in the following patches that start using length=0 in BIG TCP UDP packets. Patches 02-04 close the gaps that prevent BIG TCP packets from going through UDP tunnel code. Patch 05 validates packets in udp_gro_receive to exclude packets with length=0 from GRO aggregation. Patch 06 is for proper formatting in tcpdump (set UDP len to 0 rather than a trimmed value on overflow). Patches 07-08 bump up tso_max_size for VXLAN and GENEVE. Patch 09 adds selftests. ====================$ Link: https://patch.msgid.link/20260710134242.216538-1-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-22udp: Set length in UDP header to 0 for big GSO packetsAlice Mikityanska
skb->len may be bigger than 65535 in UDP-based tunnels that have BIG TCP enabled. If GSO aggregates packets that large, set the length in the UDP header to 0, so that tcpdump can print such packets properly (treating them as RFC 2675 jumbograms). Later in the pipeline, __udp_gso_segment will set uh->len to the size of individual packets. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260710134242.216538-7-alice.kernel@fastmail.im Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-22udp: Validate UDP length in udp_gro_receiveAlice Mikityanska
In the previous commit we started using uh->len = 0 as a marker of a GRO packet bigger than 65536 bytes. Filter out malformed packets coming from the wire with len=0 at udp_gro_receive to exclude them from GRO. Note that a similar check was present in udp_gro_receive_segment, but not in the UDP socket gro_receive flow. By adding an early check to udp_gro_receive, the check in udp_gro_receive_segment can be dropped. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260710134242.216538-6-alice.kernel@fastmail.im Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-22udp: Support gro_ipv4_max_size > 65536Alice Mikityanska
Currently, gro_max_size and gro_ipv4_max_size can be set to values bigger than 65536, and GRO will happily aggregate UDP to the configured size (for example, with TCP traffic in VXLAN tunnels). However, udp_gro_complete uses the 16-bit length field in the UDP header to store the length of the aggregated packet. It leads to the packet truncation later in udp_rcv. Fix this by storing 0 to the UDP length field and by restoring the real length from skb->len in udp_rcv. IP GRO already can store 0 to the IP length field, and iph_totlen()/ipv6_payload_len() are capable of restoring the real length, because the relevant packets (BIG TCP tunneled in UDP tunnels) will have skb_is_gso_tcp == true. Additionally, restrict handling uh->len=0 in udpv6_rcv to BIG TCP and jumbograms only by using the udp_get_len helper. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260710134242.216538-5-alice.kernel@fastmail.im Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-22udp: Support BIG TCP GSO packets where they can occurAlice Mikityanska
Wherever a GSO packet can occur, and its length is used to fill the UDP header, use udp_set_len that assigns 0 if the length doesn't fit 16 bits, so that the packet can be properly parsed and segmented later, instead of having truncated length. Use udp_get_len in udp_validate_len to treat BIG TCP packets as valid. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260710134242.216538-4-alice.kernel@fastmail.im Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-22net: Enable BIG TCP with partial GSOAlice Mikityanska
skb_segment is called for partial GSO, when netif_needs_gso returns true in validate_xmit_skb. Partial GSO is needed, for example, when segmentation of tunneled traffic is offloaded to a NIC that only supports inner checksum offload. Currently, skb_segment clamps the segment length to 65534 bytes, because gso_size == 65535 is a special value GSO_BY_FRAGS, and we don't want to accidentally assign mss = 65535, as it would fall into the GSO_BY_FRAGS check further in the function. This implementation, however, artificially blocks len > 65534, which is possible since the introduction of BIG TCP. To allow bigger lengths and avoid resegmentation of BIG TCP packets, store the gso_by_frags flag in the beginning and don't use a special value of mss for this purpose after mss was modified. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260710134242.216538-3-alice.kernel@fastmail.im Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-22net: Use helpers to get/set UDP len tree-wideAlice Mikityanska
Since BIG TCP for UDP tunnels will start using len=0 in the UDP header as an indicator of a GSO packet bigger than 65535 bytes, this commit introduces the following getter and setters to use tree-wide, in order to explicitly mark places where len=0 may be expected, and handle them properly: 1. udp_set_len() sets uh->len to its real value if it's not bigger than 65535, and to 0 otherwise: to be used in GSO context with aggregated packets. 2. udp_set_len_short() is to be used when the length is known to fit 16 bits. It WARNs when the caller tries to assign a bigger value if CONFIG_DEBUG_NET=y. 3. udp_get_len_short() returns len in host byte order: to be used on the RX side to deal with non-aggregated packets, or to access the raw value of the len field. 4. udp_get_len() decodes uh->len set by udp_set_len(). It checks whether the packet is GSO to guard from malformed packets. At the moment udp_set_len() is not used, a following commit will start using it after enabling len>65535 for GSO. Raw uh->len (in network byte order) is still accessed in a few places for checksum calculation purposes, and to decode len=0 in udpv6_rcv for jumbograms. udp_rcv and udpv6_rcv will be addressed by the commit that starts using udp_set_len() to set UDP len=0 for BIG TCP packets in UDP tunnels. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20260710134242.216538-2-alice.kernel@fastmail.im Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21tcp: initialize standalone TCP-AO response paddingYizhou Zhao
tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header. Fixes: decde2586b34 ("net/tcp: Add TCP-AO sign to twsk") Fixes: da7dfaa6d6f7 ("net/tcp: Consistently align TCP-AO option in the header") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260713105631.8616-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: qrtr: ns: Raise node count limit to 512Youssef Samir
The current node limit of 64 breaks the functionality for a number of AI200 deployments that have up to 384 nodes. Raise the limit to 512. Fixes: 27d5e84e810b ("net: qrtr: ns: Limit the total number of nodes") Cc: stable@vger.kernel.org Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Link: https://patch.msgid.link/20260713145901.212396-1-youssef.abdulrahman@oss.qualcomm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21tipc: fix infinite loop in __tipc_nl_compat_dumpitHelen Koike
cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error. Reported-by: syzbot+85d0bec020d805014a3a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=85d0bec020d805014a3a Fixes: d0796d1ef63d ("tipc: convert legacy nl bearer dump to nl compat") Signed-off-by: Helen Koike <koike@igalia.com> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Link: https://patch.msgid.link/20260713204940.647668-1-koike@igalia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21nexthop: initialize extack in nh_res_bucket_migrate()Xiang Mei (Microsoft)
nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited("%s\n", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it. Fixes: 7c37c7e00411 ("nexthop: Implement notifiers for resilient nexthop groups") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260713221551.3344650-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21tls: device: push pending open record on splice EOFRishikesh Jethwani
On kTLS device-offload sockets, sendfile() with count > EOF can reach ->splice_eof() with a fully assembled but still-open TLS record left pending. tls_device_splice_eof() only flushes partially sent records, so an abrupt close() can drop the final record and the peer receives a short file. Fix tls_device_splice_eof() to also push pending open records. This matches the software path, where splice EOF already flushes pending open records. Fixes: d4c1e80b0d1b ("tls/device: Use splice_eof() to flush") Link: https://lore.kernel.org/netdev/CAMPsyauZ+jzG9AysO0FWv6ZY0kvCUpjX_U7o=oOjCuOQ87BCgg@mail.gmail.com/ Reported-by: Nils Juenemann <nils.juenemann@gmail.com> Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com> Tested-by: Nils Juenemann <nils.juenemann@gmail.com> Link: https://patch.msgid.link/20260709224436.1608993-2-rjethwani@purestorage.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21wifi: mac80211: parse enhanced critical updates fieldJohannes Berg
For association and link reconfiguration response, parse and store the enhanced BSS parameter change counter out of the enhanced critical updates field in the multi-link common info or per-STA profile. These are required for UHR connections. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260714134154.adb9fc29252d.I625580fbadbbf4a1440d88d3675586477f1a3263@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211: refactor multi-link assoc response parsingJohannes Berg
Refactor the parsing code a bit, introducing specific error messages for the various failures and moving the BSS parameter change count parsing out a level to be easier to extend for UHR. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260714134154.e2fb22738aa1.Id86c1bd6ddb5ec13ad9cbf24fd36b8246f351fe6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: cfg80211: include cf1 offset when sending chandefLachlan Hodges
The cf1 offset is not included when sending the chandef leading to incorrect channel resolution in usermode. Include it. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20260721053958.227853-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211: notify driver before destroying assoc linkPagadala Yesu Anjaneyulu
During association completion, mac80211 must notify the driver before destroying the association link context. Previously, the driver callback drv_mgd_complete_tx() was invoked after ieee80211_destroy_assoc_data(), which left the driver with no link context to perform per-link resource cleanup operations. Move drv_mgd_complete_tx() invocation into ieee80211_destroy_assoc_data(), before link destruction. This ensures the driver has access to link context when needed for cleanup. Similar for ieee80211_destroy_auth_data(). On failed associations, the driver now has the link available to safely cancel any active sessions. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Assisted-by: GitHubCopilot:gpt-5.3-codex Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260717171018.3afb91fcaac7.I308890d98c35acf1ceb79c295526d18c8eb164b9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211: fix monitor min_def bandwidthJohannes Berg
Due to reshuffling, the min_def is no longer calculated taking a newly created monitor interface into account as link->conf->chanctx_conf is only assigned after the new bandwidth has been calculated. To handle this, rsvd_for is assigned, but the monitor code didn't handle that. Fix this by checking rsvd_for for monitor explicitly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715213312.9fe95421689d.I24e08f95e97deb46c6393ee732057d63e6436a2e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21sctp: close UDP tunnel sockets during netns teardownZhiling Zou
proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed. Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/b9f1f02b0780ad6a719e2413f5f0bb8eb7702d94.1782585631.git.roxy520tt%40gmail.com Signed-off-by: Zhiling Zou <roxy520tt@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/6dab75f22855cb219e2e30a5497cab03b970ab91.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21sctp: avoid auth_enable sysctl UAF during netns teardownZhiling Zou
proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper. Fixes: 15649fd5415e ("sctp: sysctl: auth_enable: avoid using current->nsproxy") Cc: stable@vger.kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Co-developed-by: Qi Tang <tpluszz77@gmail.com> Signed-off-by: Qi Tang <tpluszz77@gmail.com> Signed-off-by: Zhiling Zou <roxy520tt@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/390cd5e91ed60eea27b0b64d0468301a9e73b808.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21sctp: validate stream count in sctp_process_strreset_inreq()Cen Zhang (Microsoft)
When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer. Fixes: 7f9d68ac944e ("sctp: implement sender-side procedures for SSN Reset Request Parameter") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/20260707203215.2752-1-blbllhy@gmail.com/ Suggested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260710010718.20318-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()Hidayath Khan
afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Cc: stable@vger.kernel.org Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com> Link: https://patch.msgid.link/20260709191732.124092-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkidHanQuan
sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity. Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Signed-off-by: HanQuan <eilaimemedsnaimel@gmail.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260713032021.3491702-1-zhoujian.zja@antgroup.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: ipv4: clear dev->ip_ptr before destroying inetdevYuyang Huang
To prevent RCU readers from accessing a partially destroyed in_device, clear dev->ip_ptr early in inetdev_destroy() before freeing the multicast list and individual IP addresses. This aligns the IPv4 teardown sequence with the IPv6 implementation. Cc: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Yuyang Huang <yuyanghuang@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260711005405.2861680-4-yuyanghuang@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21wifi: mac80211: use ifa_dev from event argumentYuyang Huang
During address teardown, the netdevice's ip_ptr might be cleared before the inetaddr notifier is called. In this case, __in_dev_get_rtnl() returns NULL, causing the notifier to abort early and fail to update the ARP filter. Fix this by using the in_device pointer from the event argument (ifa->ifa_dev) which is guaranteed to be valid. Cc: Ido Schimmel <idosch@nvidia.com> Cc: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Yuyang Huang <yuyanghuang@google.com> Link: https://patch.msgid.link/20260711005405.2861680-3-yuyanghuang@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabledIlia Gavrilov
When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: <TASK> ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 </TASK> The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr") Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support") Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov@infotecs.ru> Reviewed-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260709162723.367523-1-Ilia.Gavrilov@infotecs.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21tipc: serialize udp bearer replicast list updatesWeiming Shi
tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions. Fixes: ef20cd4dd163 ("tipc: introduce UDP replicast") Reported-by: Xiang Mei <xmei5@asu.edu> Suggested-by: Tung Nguyen <tung.quang.nguyen@est.tech> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Link: https://patch.msgid.link/20260716025203.9332-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21mptcp: only set DATA_FIN when a mapping is presentMichael Bommarito
mptcp_get_options() clears only the status group of struct mptcp_options_received; data_seq, subflow_seq and data_len are filled in by mptcp_parse_option() exclusively inside the DSS mapping block, which runs only when the DSS M (mapping present) bit is set. A peer can send a DSS option with the DATA_FIN flag set but the mapping bit clear. The parser then records mp_opt->data_fin while leaving data_len and data_seq uninitialized. For a zero-length segment mptcp_incoming_options() evaluates if (mp_opt.data_fin && mp_opt.data_len == 1 && mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64)) which reads the uninitialized data_len and data_seq; KMSAN reports an uninit-value in mptcp_incoming_options(). The stale data_seq can also be fed into the receive-side DATA_FIN sequence tracking. Record the DATA_FIN flag only when the DSS option carries a mapping, so data_fin is never set without data_seq and data_len also being present. data_fin is part of the status group that mptcp_get_options() clears up front, so on the no-map path it stays zero and the zero-length DATA_FIN branch is simply skipped. A DATA_FIN is always transmitted together with a mapping (mptcp_write_data_fin() sets use_map along with data_seq and data_len), so legitimate DATA_FIN handling is unaffected. Move the pr_debug() that logs the parsed DSS flags below the mapping block, so it reports the final data_fin value instead of the stale one it would otherwise print before the assignment. Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine") Suggested-by: Paolo Abeni <pabeni@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260709191925.2811195-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21wifi: mac80211: ibss: read deauth reason_code after frame length checkShahar Tzarfati
The function was reading reason_code from the frame before validating that the frame is at least IEEE80211_DEAUTH_FRAME_LEN bytes long. Move the reason_code read to after the length check so the field is guaranteed to be present before it is accessed. Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715212706.db26604650bd.I2caa73c396b8c9d357224b9334d5df3cafac498e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: cfg80211: clarify and tighten key checksJohannes Berg
Currently, we accept per-STA GTK for any interface type if the IBSS_RSN flag is set, which doesn't make sense, and also accept various key indices that aren't really (meant to be) supported, such as IGTK/BIGTK on IBSS or AP_VLAN etc. For MESH and NAN_DATA interface types, per-STA GTKs are required, so their support shouldn't depend on IBSS_RSN. Conversely a driver setting IBSS_RSN doesn't really say it also accepts per-STA GTK for other interface types. Move more checks into cfg80211_valid_key_idx() and make them more precise: - allow IGTK and, if supported, BIGTK for NAN - allow per-STA (RX) GTK only for - NAN_DATA - IBSS if IBSS_RSN is supported - MESH - allow B/I/GTK for station/P2P-client without mac_addr for RX with the current AP (historic API quirk), subject to support - allow TX GTK for AP/P2P-GO/AP_VLAN - allow TX IGTK/BIGTK for AP/P2P-GO subject to support Other settings are rejected, clearing up corner cases and disallowing unexpected settings. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715212403.725e6b63e890.I24684374112bb94d0633d61ef76ecb8a1517f7f1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: cfg80211: improve multi-BSSID profile continuation parserJohannes Berg
The previous change from John Walker fixed the loop iteration, but the code is written in a bad way. Pass the pointers needed for the iteration to the function instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715211048.04877081fd0a.I48f0135ba83dcc5f0b736b61f8f9e86ecc72583f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: use UHR operation field presence bitsJohannes Berg
The spec originally had the idea that the fact that it's a beacon frame determines the (non-)presence of the values, but added presence bits in D1.4. Use those presence bits in addition to the enable bits. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715210407.3b1a79b0d002.Iaa762c55b4b6dc63d55f2d7b8b42acd47e640d50@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211: always send regulatory connectivity elementJohannes Berg
The spec says to include it if the STA is "capable of operating as STA 6G", which is a bit unclear because this is defined at a STA level and not at the MLD level or so, but WFA requires this to be included. Either way, the element is completely advisory and intended mostly for debugging (and perhaps a bit steering), so just include it in association request all the time if 6 GHz is supported. To determine what exactly to include, check all the channels that aren't disabled. That way, it ends up being a lowest common denominator, which is most useful for steering etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715210322.02a4f3fced21.I94bbd08ac38001e11d5143a8b3f54dcea8ae8e15@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211: don't encrypt pre-auth (ETH_P_PREAUTH) framesDeepanshu Kartikey
Pre-authentication frames (ETH_P_PREAUTH, 0x88C7) are sent before the authentication handshake completes with the target AP, so no encryption key exists for them yet. Unlike normal EAPOL frames (ETH_P_8021X, 0x888E) which are registered as the control port protocol, pre-auth frames are not recognized as control port frames, causing the kernel to incorrectly assign the current AP's key and attempt encryption, resulting in a WARN_ON in ieee80211_encrypt_tx_skb when the cipher is not handled. Fix this by setting IEEE80211_TX_INTFL_DONT_ENCRYPT for pre-auth frames in ieee80211_tx_h_check_control_port_protocol(), so that key selection skips them and they are sent unencrypted as intended. Note that the only driver hitting this path is hwsim. Reported-by: syzbot+b6ce23950fd636e6efb6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b6ce23950fd636e6efb6 Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260713015946.44636-1-kartikey406@gmail.com [add note about hwsim, fix subject] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21net: Call net_enable_timestamp() before failure in sk_clone().Kuniyuki Iwashima
When sk_clone() fails, sk_destruct() is called for the new socket. If the parent socket has SK_FLAGS_TIMESTAMP in sk->sk_flags, net_disable_timestamp() is called for the child socket even though net_enable_timestamp() is not called for it. Let's call net_enable_timestamp() before any failure path in sk_clone(). Fixes: 704da560c0a0 ("tcp: update the netstamp_needed counter when cloning sockets") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260709032007.9E4D61F000E9@smtp.kernel.org/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jason Xing <kerneljasonxing@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260709183315.965751-3-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21soreuseport: Clear sk_reuseport_cb before failure in sk_clone().Kuniyuki Iwashima
When sk_clone() fails, sk_destruct() is called for the new socket. If the parent socket has sk->sk_reuseport_cb, the child will call reuseport_detach_sock() for the reuseport group. Let's clear sk->sk_reuseport_cb before any failure path in sk_clone(). Note that this was not a problem before the cited commit because reuseport_detach_sock() did nothing if the socket was not found in the reuseport array. Fixes: 5dc4c4b7d4e8 ("bpf: Introduce BPF_MAP_TYPE_REUSEPORT_SOCKARRAY") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260709032007.9E4D61F000E9@smtp.kernel.org/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jason Xing <kerneljasonxing@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260709183315.965751-2-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/tcp: Prevent inlining tcp_syn_ack_timeout()Emil Tsalapatis
The tcp_syn_ack_timeout() function gets inlined by Clang, preventing tracing. Since the call is not in the fast path, prevent it from being inlined. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260708180837.9507-1-emil@etsalapatis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: gro: fix double aggregation of flush-marked skbsShiming Cheng
Commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO packet.") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive(). Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.") Cc: stable@vger.kernel.org Signed-off-by: Shiming Cheng <shiming.cheng@mediatek.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260709014704.3625-1-shiming.cheng@mediatek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21wifi: cfg80211: guard optional PMSR nominal timeZhao Li
pmsr_parse_ftm() rejects a request that omits NOMINAL_TIME only for non-trigger-based PD ranging. It then reads the attribute unconditionally for every non-trigger-based request: out->ftm.nominal_time = nla_get_u32(tb[NL80211_PMSR_FTM_REQ_ATTR_NOMINAL_TIME]); For the other non-trigger-based request types NOMINAL_TIME is optional, so tb[...] can be NULL and nla_get_u32() dereferences a NULL pointer. Keep the requirement for PD ranging and read the nominal-time value only when the attribute is present. Fixes: 8823a9b0e7af ("wifi: cfg80211: add NTB continuous ranging and FTM request type support") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li <enderaoelyther@gmail.com> Link: https://patch.msgid.link/20260708195911.84365-5-enderaoelyther@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211: recalculate TIM when a station enters power saveAndrew Pope
When an AP buffers frames for a station on its per-station TXQs and the station subsequently enters power save, sta_ps_start() records the buffered TIDs in txq_buffered_tids but does not update the TIM. The station's TIM bit is only ever set when a further frame is buffered while the station is already asleep (ieee80211_tx_h_unicast_ps_buf() -> sta_info_recalc_tim()). If no further downlink frame arrives for that station the beacon TIM never advertises the buffered traffic. A station relying on the TIM then remains in doze indefinitely on top of a non-empty queue. Its TXQs were removed from the scheduler's active list at PS entry, nothing pages it, and the flow deadlocks until an unrelated event wakes the station. Recalculate the TIM at the end of sta_ps_start(), so traffic already buffered at PS entry is advertised immediately. sta_info_recalc_tim() already consults txq_buffered_tids, which is updated above, and is safe in this context (it is already called from equivalent paths such as the tx handlers and ieee80211_handle_filtered_frame()). Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Signed-off-by: Andrew Pope <andrew.pope@morsemicro.com> Link: https://patch.msgid.link/20260717011751.79524-1-andrew.pope@morsemicro.com [add wifi: subject prefix] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211: copy aggregation informationBenjamin Berg
This information can be considered part of the capabilities and should also be copied to the NAN data station. Fixes: 27e9b326b674 ("wifi: mac80211: support NAN stations") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260714141038.15620aa5324b.I049254b854ac91c32e0768eb7c819f32eda34218@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211: tear down new links on vif update error pathXiang Mei
When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f ("wifi: mac80211: avoid weird state in error path") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception Fixes: 170cd6a66d9a ("wifi: mac80211: add netdev per-link debugfs data and driver hook") Reported-by: Weiming Shi <bestswngs@gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://patch.msgid.link/20260711210302.2098404-1-xmei5@asu.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-20 03:39:26 +0000