- 08 Aug, 2023 5 commits
-
-
Felix Fietkau authored
AP_VLAN interfaces are virtual, so doesn't really exist as a type for capabilities. When passed in as a type, AP is the one that's really intended. Fixes: c4cbaf79 ("cfg80211: Add support for HE") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230622165919.46841-1-nbd@nbd.nameSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Ping-Ke Shih authored
RX full flags are raised if certain types of RX FIFO are full, and then drop all following MPDU of AMPDU. In order to resume to receive MPDU when RX FIFO becomes available, we clear the register bits by the commit a0d99ebb ("wifi: rtw89: initialize DMA of CMAC"). But, 8852AE needs more settings to support this. To quickly fix disconnection problem, revert the behavior as before. Fixes: a0d99ebb ("wifi: rtw89: initialize DMA of CMAC") Reported-by:
Damian B <bronecki.damian@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217710 Cc: <Stable@vger.kernel.org> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Tested-by:
-
Larry Finger authored
This entry is not needed. Remove it. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Link: https://lore.kernel.org/r/20230804222438.16076-3-Larry.Finger@lwfinger.netSigned-off-by:
-
Larry Finger authored
As Herton Ronaldo Krzesinski is no longer active, remove him as maintainer for rtl8187. The git tree entry is also removed. Signed-off-by:
-
Petr Tesarik authored
Return -ENOMEM from brcmf_run_escan() if kzalloc() fails for v1 params. Fixes: 398ce273 ("wifi: brcmfmac: cfg80211: Add support for scan params v2") Signed-off-by:
Petr Tesarik <petr.tesarik.ext@huawei.com> Link: https://lore.kernel.org/r/20230802163430.1656-1-petrtesarik@huaweicloud.comSigned-off-by:
-
- 02 Aug, 2023 1 commit
-
-
Hans de Goede authored
Using brcmfmac with 6.5-rc3 on a brcmfmac43241b4-sdio triggers a backtrace caused by the following field-spanning warning: memcpy: detected field-spanning write (size 120) of single field "¶ms_le->channel_list[0]" at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1072 (size 2) The driver still works after this warning. The warning was introduced by the new field-spanning write checks which were enabled recently. Fix this by replacing the channel_list[1] declaration at the end of the struct with a flexible array declaration. Most users of struct brcmf_scan_params_le calculate the size to alloc using the size of the non flex-array part of the struct + needed extra space, so they do not care about sizeof(struct brcmf_scan_params_le). brcmf_notify_escan_complete() however uses the struct on the stack, expecting there to be room for at least 1 entry in the channel-list to store the special -1 abort channel-id. To make this work use an anonymous union with a padding member added + the actual channel_list flexible array. Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230729140500.27892-1-hdegoede@redhat.com
-
- 01 Aug, 2023 1 commit
-
-
Kees Cook authored
The trailing array member of struct tx_buf was defined as a 1-element array, but used as a flexible array. This was resulting in build warnings: In function 'fortify_memset_chk', inlined from 'memset_io' at /kisskb/src/arch/mips/include/asm/io.h:486:2, inlined from 'build_auth_frame' at /kisskb/src/drivers/net/wireless/legacy/ray_cs.c:2697:2: /kisskb/src/include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 493 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Replace it with an actual flexible array. Binary difference comparison shows a single change in output: │ drivers/net/wireless/legacy/ray_cs.c:883 │ lea 0x1c(%rbp),%r13d │ - cmp $0x7c3,%r13d │ + cmp $0x7c4,%r13d This is from: if (len + TX_HEADER_LENGTH > TX_BUF_SIZE) { specifically: #define TX_BUF_SIZE (2048 - sizeof(struct tx_msg)) This appears to have been originally buggy, so the change is correct. Reported-by:Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/88f83d73-781d-bdc-126-aa629cb368c@linux-m68k.org Cc: Kalle Valo <kvalo@kernel.org> Cc: linux-wireless@vger.kernel.org Signed-off-by:
-
- 26 Jul, 2023 13 commits
-
-
Kalle Valo authored
Jeff will now start maintaining these drivers together with me. Signed-off-by:
-
Kalle Valo authored
Last activity from Lennert is from 2012 so mark the driver as orphan. Signed-off-by:
-
Kalle Valo authored
There's no maintainer for b43 so mark it as orphan. Signed-off-by:
-
Kalle Valo authored
Last activity from Ulrich is from 2007 so mark the driver orphan. Remove the zd1211-devs list, I doubt anyone uses it anymore. The webpage seems to be down so remove that as well. Signed-off-by:
-
Kalle Valo authored
There's no maintainer for this driver so mark it as orphan. Signed-off-by:
-
Kalle Valo authored
Last activity from Jussi for this driver is from 2013 so mark the driver orphan. Signed-off-by:
-
Kalle Valo authored
Last activity from Pontus for this driver is from 2013 so mark the driver orphan. Signed-off-by:
-
Kalle Valo authored
Last activity from Solomon is from 2013 so mark the driver orphan. Signed-off-by:
-
Kalle Valo authored
Last activity from Simon is from 2005 so mark the driver is orphan. Signed-off-by:
-
Kalle Valo authored
Yan-Hsuan has been away since 2021 and Ping has been the de facto maintainer the past year, actively reviewing patches and doing all other maintainer duties. So fix the MAINTAINERS file to show the current situation. Signed-off-by:
-
Kalle Valo authored
This reverts commit bd1d129d. The dangling-pointer warnings were disabled kernel-wide by commit 49beadbd ("gcc-12: disable '-Wdangling-pointer' warning for now") for v5.19. So this hack in ath6kl is not needed anymore. Signed-off-by:
-
Ilan Peer authored
The reporter noticed a warning when running iwlwifi: WARNING: CPU: 8 PID: 659 at mm/page_alloc.c:4453 __alloc_pages+0x329/0x340 As cfg80211_parse_colocated_ap() is not expected to return a negative value return 0 and not a negative value if cfg80211_calc_short_ssid() fails. Fixes: c8cb5b85 ("nl80211/cfg80211: support 6 GHz scanning") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217675Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Kalle Valo authored
This reverts commit 13aa2fb6. This commit broke QCN9074 initialisation: [ 358.960477] ath11k_pci 0000:04:00.0: ce desc not available for wmi command 36866 [ 358.960481] ath11k_pci 0000:04:00.0: failed to send WMI_STA_POWERSAVE_PARAM_CMDID [ 358.960484] ath11k_pci 0000:04:00.0: could not set uapsd params -105 As there's no fix available let's just revert it to get QCN9074 working again. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217536Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Signed-off-by:
-
- 24 Jul, 2023 2 commits
-
-
Brian Norris authored
We haven't heard anything from these folks in years. I've been reviewing many submissions and plan to keep doing so. Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Ganapathi Bhat <ganapathi017@gmail.com> Cc: Sharvari Harisangam <sharvari.harisangam@nxp.com> Cc: Xinming Hu <huxinming820@gmail.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Paul Fertser authored
On DBDC devices the first (internal) phy is only capable of using 2.4 GHz band, and the 5 GHz band is exposed via a separate phy object, so avoid the false advertising. Reported-by:
Rani Hod <rani.hod@gmail.com> Closes: https://github.com/openwrt/openwrt/pull/12361 Fixes: 7660a1bd ("mt76: mt7615: register ext_phy if DBDC is detected") Cc: stable@vger.kernel.org Signed-off-by:
Paul Fertser <fercerpav@gmail.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Acked-by:
-
- 20 Jul, 2023 10 commits
-
-
Paolo Abeni authored
Kuniyuki Iwashima says: ==================== net: Support STP on bridge in non-root netns. Currently, STP does not work in non-root netns as llc_rcv() drops packets from non-root netns. This series fixes it by making some protocol handlers netns-aware, which are called from llc_rcv() as follows: llc_rcv() | |- sap->rcv_func : registered by llc_sap_open() | | * functions : regsitered by register_8022_client() | -> No in-kernel user call register_8022_client() | | * snap_rcv() | | | `- proto->rcvfunc() : registered by register_snap_client() | | * aarp_rcv() : drop packets from non-root netns | * atalk_rcv() : drop packets from non-root netns | | * stp_pdu_rcv() | | | `- garp_protos[]->rcv() : registered by stp_proto_register() | | * garp_pdu_rcv() : netns-aware | * br_stp_rcv() : netns-aware | |- llc_type_handlers[llc_pdu_type(skb) - 1] | | * llc_sap_handler() : NOT netns-aware (Patch 1) | * llc_conn_handler() : NOT netns-aware (Patch 2) | `- llc_station_handler * llc_station_rcv() : netns-aware Patch 1 & 2 convert not-netns-aware functions and Patch 3 remove the netns restriction in llc_rcv(). Note this series does not namespacify AF_LLC so that these patches can be backported to stable without conflicts (at least to 4.14.y). Another series that adds netns support for AF_LLC will be targeted to net-next later. ==================== Link: https://lore.kernel.org/r/20230718174152.57408-1-kuniyu@amazon.comSigned-off-by:Paolo Abeni <pabeni@redhat.com>
-
Kuniyuki Iwashima authored
This reverts commit 56a16035. Since the previous commit, STP works on bridge in netns. # unshare -n # ip link add br0 type bridge # ip link add veth0 type veth peer name veth1 # ip link set veth0 master br0 up [ 50.558135] br0: port 1(veth0) entered blocking state [ 50.558366] br0: port 1(veth0) entered disabled state [ 50.558798] veth0: entered allmulticast mode [ 50.564401] veth0: entered promiscuous mode # ip link set veth1 master br0 up [ 54.215487] br0: port 2(veth1) entered blocking state [ 54.215657] br0: port 2(veth1) entered disabled state [ 54.215848] veth1: entered allmulticast mode [ 54.219577] veth1: entered promiscuous mode # ip link set br0 type bridge stp_state 1 # ip link set br0 up [ 61.960726] br0: port 2(veth1) entered blocking state [ 61.961097] br0: port 2(veth1) entered listening state [ 61.961495] br0: port 1(veth0) entered blocking state [ 61.961653] br0: port 1(veth0) entered listening state [ 63.998835] br0: port 2(veth1) entered blocking state [ 77.437113] br0: port 1(veth0) entered learning state [ 86.653501] br0: received packet on veth0 with own address as source address (addr:6e:0f:e7:6f:5f:5f, vlan:0) [ 92.797095] br0: port 1(veth0) entered forwarding state [ 92.797398] br0: topology change detected, propagating Let's remove the warning. Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
-
Kuniyuki Iwashima authored
Now these upper layer protocol handlers can be called from llc_rcv() as sap->rcv_func(), which is registered by llc_sap_open(). * function which is passed to register_8022_client() -> no in-kernel user calls register_8022_client(). * snap_rcv() `- proto->rcvfunc() : registered by register_snap_client() -> aarp_rcv() and atalk_rcv() drop packets from non-root netns * stp_pdu_rcv() `- garp_protos[]->rcv() : registered by stp_proto_register() -> garp_pdu_rcv() and br_stp_rcv() are netns-aware So, we can safely remove the netns restriction in llc_rcv(). Fixes: e730c155 ("[NET]: Make packet reception network namespace safe") Signed-off-by: -
Kuniyuki Iwashima authored
We will remove this restriction in llc_rcv() in the following patch, which means that the protocol handler must be aware of netns. if (!net_eq(dev_net(dev), &init_net)) goto drop; llc_rcv() fetches llc_type_handlers[llc_pdu_type(skb) - 1] and calls it if not NULL. If the PDU type is LLC_DEST_CONN, llc_conn_handler() is called to pass skb to corresponding sockets. Then, we must look up a proper socket in the same netns with skb->dev. llc_conn_handler() calls __llc_lookup() to look up a established or litening socket by __llc_lookup_established() and llc_lookup_listener(). Both functions iterate on a list and call llc_estab_match() or llc_listener_match() to check if the socket is the correct destination. However, these functions do not check netns. Also, bind() and connect() call llc_establish_connection(), which finally calls __llc_lookup_established(), to check if there is a conflicting socket. Let's test netns in llc_estab_match() and llc_listener_match(). Signed-off-by: -
Kuniyuki Iwashima authored
We will remove this restriction in llc_rcv() soon, which means that the protocol handler must be aware of netns. if (!net_eq(dev_net(dev), &init_net)) goto drop; llc_rcv() fetches llc_type_handlers[llc_pdu_type(skb) - 1] and calls it if not NULL. If the PDU type is LLC_DEST_SAP, llc_sap_handler() is called to pass skb to corresponding sockets. Then, we must look up a proper socket in the same netns with skb->dev. If the destination is a multicast address, llc_sap_handler() calls llc_sap_mcast(). It calculates a hash based on DSAP and skb->dev->ifindex, iterates on a socket list, and calls llc_mcast_match() to check if the socket is the correct destination. Then, llc_mcast_match() checks if skb->dev matches with llc_sk(sk)->dev. So, we need not check netns here. OTOH, if the destination is a unicast address, llc_sap_handler() calls llc_lookup_dgram() to look up a socket, but it does not check the netns. Therefore, we need to add netns check in llc_lookup_dgram(). Signed-off-by:
-
Daniel Golle authored
entries and bind debugfs files would display wrong data on NETSYS_V2 and later because instead of using mtk_get_ib1_pkt_type the driver would use MTK_FOE_IB1_PACKET_TYPE which corresponds to NETSYS_V1(.x) SoCs. Use mtk_get_ib1_pkt_type so entries and bind records display correctly. Fixes: 03a3180e ("net: ethernet: mtk_eth_soc: introduce flow offloading support for mt7986") Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Acked-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/c0ae03d0182f4d27b874cbdf0059bc972c317f3c.1689727134.git.daniel@makrotopia.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Heiner Kallweit says: ==================== r8169: revert two changes that caused regressions This reverts two changes that caused regressions. ==================== Link: https://lore.kernel.org/r/ddadceae-19c9-81b8-47b5-a4ff85e2563a@gmail.comSigned-off-by:
-
Heiner Kallweit authored
This reverts commit e1ed3e4d. Turned out the change causes a performance regression. Link: https://lore.kernel.org/netdev/20230713124914.GA12924@green245/T/ Cc: stable@vger.kernel.org Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/055c6bc2-74fa-8c67-9897-3f658abb5ae7@gmail.comSigned-off-by:
-
Heiner Kallweit authored
r8169: revert 2ab19de6 ("r8169: remove ASPM restrictions now that ASPM is disabled during NAPI poll") There have been reports that on a number of systems this change breaks network connectivity. Therefore effectively revert it. Mainly affected seem to be systems where BIOS denies ASPM access to OS. Due to later changes we can't do a direct revert. Fixes: 2ab19de6 ("r8169: remove ASPM restrictions now that ASPM is disabled during NAPI poll") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/e47bac0d-e802-65e1-b311-6acb26d5cf10@freenet.de/T/ Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217596Signed-off-by:
-
Kuniyuki Iwashima authored
This reverts commit 3f4ca5fa. Commit 3f4ca5fa ("tcp: avoid the lookup process failing to get sk in ehash table") reversed the order in how a socket is inserted into ehash to fix an issue that ehash-lookup could fail when reqsk/full sk/twsk are swapped. However, it introduced another lookup failure. The full socket in ehash is allocated from a slab with SLAB_TYPESAFE_BY_RCU and does not have SOCK_RCU_FREE, so the socket could be reused even while it is being referenced on another CPU doing RCU lookup. Let's say a socket is reused and inserted into the same hash bucket during lookup. After the blamed commit, a new socket is inserted at the end of the list. If that happens, we will skip sockets placed after the previous position of the reused socket, resulting in ehash lookup failure. As described in Documentation/RCU/rculist_nulls.rst, we should insert a new socket at the head of the list to avoid such an issue. This issue, the swap-lookup-failure, and another variant reported in [0] can all be handled properly by adding a locked ehash lookup suggested by Eric Dumazet [1]. However, this issue could occur for every packet, thus more likely than the other two races, so let's revert the change for now. Link: https://lore.kernel.org/netdev/20230606064306.9192-1-duanmuquan@baidu.com/ [0] Link: https://lore.kernel.org/netdev/CANn89iK8snOz8TYOhhwfimC7ykYA78GA3Nyv8x06SZYa1nKdyA@mail.gmail.com/ [1] Fixes: 3f4ca5fa ("tcp: avoid the lookup process failing to get sk in ehash table") Signed-off-by:
-
- 19 Jul, 2023 8 commits
-
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski authored
Alexei Starovoitov says: ==================== pull-request: bpf 2023-07-19 We've added 4 non-merge commits during the last 1 day(s) which contain a total of 3 files changed, 55 insertions(+), 10 deletions(-). The main changes are: 1) Fix stack depth check in presence of async callbacks, from Kumar Kartikeya Dwivedi. 2) Fix BTI type used for freplace attached functions, from Alexander Duyck. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf, arm64: Fix BTI type used for freplace attached functions selftests/bpf: Add more tests for check_max_stack_depth bug bpf: Repeat check_max_stack_depth for async callbacks bpf: Fix subprog idx logic in check_max_stack_depth ==================== Link: https://lore.kernel.org/r/20230719174502.74023-1-alexei.starovoitov@gmail.comSigned-off-by:
-
Yuanjun Gong authored
goto free_skb if an unexpected result is returned by pskb_tirm() in erspan_xmit(). Signed-off-by:
Yuanjun Gong <ruc_gongyuanjun@163.com> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
Yuanjun Gong authored
goto err_free_skb if an unexpected result is returned by pskb_tirm() in erspan_fb_xmit(). Signed-off-by:
-
Yuanjun Gong authored
ocelot_fdma_receive_skb should return false if an unexpected value is returned by pskb_trim. Signed-off-by:
-
Yuanjun Gong authored
in emac_tso_csum(), return an error code if an unexpected value is returned by pskb_trim(). Signed-off-by:
-
Yuanjun Gong authored
goto tx_err if an unexpected result is returned by pskb_tirm() in ip6erspan_tunnel_xmit(). Fixes: 5a963eb6 ("ip6_gre: Add ERSPAN native tunnel support") Signed-off-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
-
Wang Ming authored
key might contain private part of the key, so better use kfree_sensitive to free it. Fixes: 38320c70 ("[IPSEC]: Use crypto_aead and authenc in ESP") Signed-off-by:
Wang Ming <machel@vivo.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-07-17 (iavf) This series contains updates to iavf driver only. Ding Hui fixes use-after-free issue by calling netif_napi_del() for all allocated q_vectors. He also resolves out-of-bounds issue by not updating to new values when timeout is encountered. Marcin and Ahmed change the way resets are handled so that the callback operating under the RTNL lock will wait for the reset to finish, the rtnl_lock sensitive functions in reset flow will schedule the netdev update for later in order to remove circular dependency with the critical lock. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: iavf: fix reset task race with iavf_remove() iavf: fix a deadlock caused by rtnl and driver's lock circular dependencies Revert "iavf: Do not restart Tx queues after reset task failure" Revert "iavf: Detach device during reset task" iavf: Wait for reset in callbacks which trigger it iavf: use internal state to free traffic IRQs iavf: Fix out-of-bounds when setting channels on remove iavf: Fix use-after-free in free_netdev ==================== Link: https://lore.kernel.org/r/20230717175205.3217774-1-anthony.l.nguyen@intel.comSigned-off-by:
-
