- 02 Jun, 2022 10 commits
-
-
Alexander Lobakin authored
Global `-Warray-bounds` enablement revealed some problems, one of which is the way we define and use AQC rules messages. In fact, they have a shared header, followed by the actual message, which can be of one of several different formats. So it is straightforward enough to define that header as a separate struct and then embed it into message structures as needed, but currently all the formats reside in one union coupled with the header. Then, the code allocates only the memory needed for a particular message format, leaving the union potentially incomplete. There are no actual reads or writes beyond the end of an allocated chunk, but at the same time, the whole implementation is fragile and backed by an equilibrium rather than strong type and memory checks. Define the structures the other way around: one for the common header and the rest for the actual formats with the header embedded. There are no places where several union members would be used at the same time anyway. This allows to use proper struct_size() and let the compiler know what is going to be done. Finally, unsilence `-Warray-bounds` back for ice_switch.c. Other little things worth mentioning: * &ice_sw_rule_vsi_list_query is not used anywhere, remove it. It's weird anyway to talk to hardware with purely kernel types (bitmaps); * expand the ICE_SW_RULE_*_SIZE() macros to pass a structure variable name to struct_size() to let it do strict typechecking; * rename ice_sw_rule_lkup_rx_tx::hdr to ::hdr_data to keep ::hdr for the header structure to have the same name for it constistenly everywhere; * drop the duplicate of %ICE_SW_RULE_RX_TX_NO_HDR_SIZE residing in ice_switch.h. Fixes: 9daf8208 ("ice: Add support for switch filter programming") Fixes: 66486d89 ("ice: replace single-element array used for C struct hack") Signed-off-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Reviewed-by:
Marcin Szycik <marcin.szycik@linux.intel.com> Acked-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20220601105924.2841410-1-alexandr.lobakin@intel.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Fei Qin authored
NFDK firmware supports 48-bit dma addressing and parses 16 high bits of dma addresses. In nfp_nfdk_tx_desc, dma related structure and tso related structure are union. When "mss" be filled with nonzero value due to enable tso, the memory used by "padding" may be also filled. Then, firmware may parse wrong dma addresses which causes TX watchdog timeout problem. This patch removes padding and unifies the dma_addr_hi bits with the one in firmware. nfp_nfdk_tx_desc_set_dma_addr is also added to match this change. Fixes: c10d12e3 ("nfp: add support for NFDK data path") Signed-off-by:
Fei Qin <fei.qin@corigine.com> Signed-off-by:
Yinjun Zhang <yinjun.zhang@corigine.com> Signed-off-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20220601083449.50556-1-simon.horman@corigine.comSigned-off-by:
-
Duoming Zhou authored
There are session cleanup problems in ax25_release() and ax25_disconnect(). If we setup a session and then disconnect, the disconnected session is still in "LISTENING" state that is shown below. Active AX.25 sockets Dest Source Device State Vr/Vs Send-Q Recv-Q DL9SAU-4 DL9SAU-3 ??? LISTENING 000/000 0 0 DL9SAU-3 DL9SAU-4 ??? LISTENING 000/000 0 0 The first reason is caused by del_timer_sync() in ax25_release(). The timers of ax25 are used for correct session cleanup. If we use ax25_release() to close ax25 sessions and ax25_dev is not null, the del_timer_sync() functions in ax25_release() will execute. As a result, the sessions could not be cleaned up correctly, because the timers have stopped. In order to solve this problem, this patch adds a device_up flag in ax25_dev in order to judge whether the device is up. If there are sessions to be cleaned up, the del_timer_sync() in ax25_release() will not execute. What's more, we add ax25_cb_del() in ax25_kill_by_device(), because the timers have been stopped and there are no functions that could delete ax25_cb if we do not call ax25_release(). Finally, we reorder the position of ax25_list_lock in ax25_cb_del() in order to synchronize among different functions that call ax25_cb_del(). The second reason is caused by improper check in ax25_disconnect(). The incoming ax25 sessions which ax25->sk is null will close heartbeat timer, because the check "if(!ax25->sk || ..)" is satisfied. As a result, the session could not be cleaned up properly. In order to solve this problem, this patch changes the improper check to "if(ax25->sk && ..)" in ax25_disconnect(). What`s more, the ax25_disconnect() may be called twice, which is not necessary. For example, ax25_kill_by_device() calls ax25_disconnect() and sets ax25->state to AX25_STATE_0, but ax25_release() calls ax25_disconnect() again. In order to solve this problem, this patch add a check in ax25_release(). If the flag of ax25->sk equals to SOCK_DEAD, the ax25_disconnect() in ax25_release() should not be executed. Fixes: 82e31755 ("ax25: Fix UAF bugs in ax25 timers") Fixes: 8a367e74 ("ax25: Fix segfault after sock connection timeout") Reported-and-tested-by:
Thomas Osterried <thomas@osterried.de> Signed-off-by:
Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20220530152158.108619-1-duoming@zju.edu.cnSigned-off-by:
-
Slark Xiao authored
Adding support for Cinterion device MV31 with Qualcomm new baseline. Use different PIDs to separate it from previous base line products. All interfaces settings keep same as previous. T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e2d ProdID=00b9 Rev=04.14 S: Manufacturer=Cinterion S: Product=Cinterion PID 0x00B9 USB Mobile Broadband S: SerialNumber=90418e79 C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option Signed-off-by:
Slark Xiao <slark_xiao@163.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20220601040531.6016-1-slark_xiao@163.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== mlx5 fixes 2022-05-31 This series provides bug fixes to mlx5 driver. Please pull and let me know if there is any problem. * tag 'mlx5-fixes-2022-05-31' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5: Fix mlx5_get_next_dev() peer device matching net/mlx5e: Update netdev features after changing XDP state net/mlx5: correct ECE offset in query qp output net/mlx5e: Disable softirq in mlx5e_activate_rq to avoid race condition net/mlx5: CT: Fix header-rewrite re-use for tupels net/mlx5e: TC NIC mode, fix tc chains miss table net/mlx5: Don't use already freed action pointer ==================== Link: https://lore.kernel.org/r/20220531205447.99236-1-saeed@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Íñigo Huguet says: ==================== sfc/siena: fix some efx_separate_tx_channels errors Trying to load sfc driver with modparam efx_separate_tx_channels=1 resulted in errors during initialization and not being able to use the NIC. This patches fix a few bugs and make it work again. This has been already done for sfc, do it also for sfc_siena. ==================== Link: https://lore.kernel.org/r/20220601063603.15362-1-ihuguet@redhat.comSigned-off-by:
-
Íñigo Huguet authored
tx_channel_offset is calculated in efx_allocate_msix_channels, but it is also calculated again in efx_set_channels because it was originally done there, and when efx_allocate_msix_channels was introduced it was forgotten to be removed from efx_set_channels. Moreover, the old calculation is wrong when using efx_separate_tx_channels because now we can have XDP channels after the TX channels, so n_channels - n_tx_channels doesn't point to the first TX channel. Remove the old calculation from efx_set_channels, and add the initialization of this variable if MSI or legacy interrupts are used, next to the initialization of the rest of the related variables, where it was missing. This has been already done for sfc, do it also for sfc_siena. Fixes: 3990a8ff ("sfc: allocate channels for XDP tx queues") Reported-by:
Tianhao Zhao <tizhao@redhat.com> Signed-off-by:
Íñigo Huguet <ihuguet@redhat.com> Acked-by:
Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by:
-
Martin Habets authored
Normally, all channels have RX and TX queues, but this is not true if modparam efx_separate_tx_channels=1 is used. In that cases, some channels only have RX queues and others only TX queues (or more preciselly, they have them allocated, but not initialized). Fix efx_channel_has_tx_queues to return the correct value for this case too. This has been already done for sfc, do it also for sfc_siena. Messages shown at probe time before the fix: sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0 ------------[ cut here ]------------ netdevice: ens6f0np0: failed to initialise TXQ -1 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped Call Trace: efx_init_tx_queue+0xaa/0xf0 [sfc] efx_start_channels+0x49/0x120 [sfc] efx_start_all+0x1f8/0x430 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xd0/0x190 __dev_change_flags+0x1b3/0x220 dev_change_flags+0x21/0x60 [...] stripped Messages shown at remove time before the fix: sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues sfc 0000:03:00.0 ens6f0np0: failed to flush queues Fixes: 8700aff0 ("sfc: fix channel allocation with brute force") Reported-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsecJakub Kicinski authored
Steffen Klassert says: ==================== ipsec 2022-06-01 1) Revert "net: af_key: add check for pfkey_broadcast in function pfkey_process" From Michal Kubecek. 2) Don't set IPv4 DF bit when encapsulating IPv6 frames below 1280 bytes. From Maciej Żenczykowski. * 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm: do not set IPv4 DF flag when encapsulating IPv6 frames <= 1280 bytes. Revert "net: af_key: add check for pfkey_broadcast in function pfkey_process" ==================== Link: https://lore.kernel.org/r/20220601103349.2297361-1-steffen.klassert@secunet.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wirelessJakub Kicinski authored
Kalle Valo says: ==================== wireless fixes for v5.19 First set of fixes for v5.19. Build fixes for iwlwifi and libertas, a scheduling while atomic fix for rtw88 and use-after-free fix for mac80211. * tag 'wireless-2022-06-01' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: mac80211: fix use-after-free in chanctx code wifi: rtw88: add a work to correct atomic scheduling warning of ::set_tim wifi: iwlwifi: pcie: rename CAUSE macro wifi: libertas: use variable-size data in assoc req/resp cmd ==================== Link: https://lore.kernel.org/r/20220601110741.90B28C385A5@smtp.kernel.orgSigned-off-by:
-
- 01 Jun, 2022 10 commits
-
-
Tobias Klauser authored
Use plain 255 instead, which also avoid introducing an additional header dependency on <linux/types.h> Fixes: 26859240 ("txhash: Add socket option to control TX hash rethink behavior") Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Link: https://lore.kernel.org/r/20220531094345.13801-1-tklauser@distanz.chSigned-off-by:
-
Dan Carpenter authored
The tcf_ct_flow_table_fill_tuple_ipv6() function is supposed to return false on failure. It should not return negatives because that means succes/true. Fixes: fcb6aa86 ("act_ct: Support GRE offload") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Toshiaki Makita <toshiaki.makita1@gmail.com> Link: https://lore.kernel.org/r/YpYFnbDxFl6tQ3Bn@kiliSigned-off-by:
-
Aya Levin authored
When passing interface parameter to ping -6: $ ping -6 ::11:141:84:9 -I eth2 Results in: PING ::11:141:84:10(::11:141:84:10) from ::11:141:84:9 eth2: 56 data bytes ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument Initialize the fl6's outgoing interface (OIF) before triggering ip6_datagram_send_ctl. Don't wipe fl6 after ip6_datagram_send_ctl() as changes in fl6 that may happen in the function are overwritten explicitly. Update comment accordingly. Fixes: 13651224 ("net: ping6: support setting basic SOL_IPV6 options via cmsg") Signed-off-by:
Aya Levin <ayal@nvidia.com> Reviewed-by:
Gal Pressman <gal@nvidia.com> Reviewed-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20220531084544.15126-1-tariqt@nvidia.comSigned-off-by:
-
Ziyang Xuan authored
Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following: ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161 Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748 Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327 After commit faab39f6 ("net: allow out-of-order netdev unregistration") and commit e5f80fcf ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem. Fixes: 2bce1ebe ("macsec: fix refcnt leak in module exit routine") Reported-by: syzbot+d0e94b65ac259c29ce7a@syzkaller.appspotmail.com Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Link: https://lore.kernel.org/r/20220531074500.1272846-1-william.xuanziyang@huawei.comSigned-off-by:
-
Dan Carpenter authored
The is_valid_offset() function returns success/true if the call to validate_and_get_cpt_blkaddr() fails. Fixes: ecad2ce8 ("octeontx2-af: cn10k: Add mailbox to configure reassembly timeout") Signed-off-by:
-
Johannes Berg authored
In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx. Cc: stable@vger.kernel.org Fixes: 5bcae31d ("mac80211: implement multi-vif in-place reservations") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220601091926.df419d91b165.I17a9b3894ff0b8323ce2afdb153b101124c821e5@changeid
-
Hangbin Liu authored
Guard ns_targets in struct bond_params by CONFIG_IPV6, which could save 256 bytes if IPv6 not configed. Also add this protection for function bond_is_ip6_target_ok() and bond_get_targets_ip6(). Remove the IS_ENABLED() check for bond_opts[] as this will make BOND_OPT_NS_TARGETS uninitialized if CONFIG_IPV6 not enabled. Add a dummy bond_option_ns_ip6_targets_set() for this situation. Fixes: 4e24be01 ("bonding: add new parameter ns_targets") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Jonathan Toppins <jtoppins@redhat.com> Link: https://lore.kernel.org/r/20220531063727.224043-1-liuhangbin@gmail.comSigned-off-by:
-
Eric Dumazet authored
Laurent reported the enclosed report [1] This bug triggers with following coditions: 0) Kernel built with CONFIG_DEBUG_PREEMPT=y 1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one. 2) A socket operation on this socket goes through lock_sock() release_sock() dance. 3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog. 4) At release_sock() time, the socket backlog is processed while in process context. 5) A SYNACK packet is cooked in response of the SYN retransmit. 6) -> tcp_rtx_synack() is called in process context. Before blamed commit, tcp_rtx_synack() was always called from BH handler, from a timer handler. Fix this by using TCP_INC_STATS() & NET_INC_STATS() which do not assume caller is in non preemptible context. [1] BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180 caller is tcp_rtx_synack.part.0+0x36/0xc0 CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1 Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021 Call Trace: <TASK> dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 168a8f58 ("tcp: TCP Fast Open Server - main code path") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Laurent Fasnacht <laurent.fasnacht@proton.ch> Acked-by:
Neal Cardwell <ncardwell@google.com> Link: https://lore.kernel.org/r/20220530213713.601888-1-eric.dumazet@gmail.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nfJakub Kicinski authored
Pablo Neira Ayuso says: ==================== Netfilter fixes for net 1) Missing proper sanitization for nft_set_desc_concat_parse(). 2) Missing mutex in nf_tables pre_exit path. 3) Possible double hook unregistration from clean_net path. 4) Missing FLOWI_FLAG_ANYSRC flag in flowtable route lookup. Fix incorrect source and destination address in case of NAT. Patch from wenxu. * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: flowtable: fix nft_flow_route source address for nat case netfilter: flowtable: fix missing FLOWI_FLAG_ANYSRC flag netfilter: nf_tables: double hook unregistration in netns path netfilter: nf_tables: hold mutex on netns pre_exit path netfilter: nf_tables: sanitize nft_set_desc_concat_parse() ==================== Link: https://lore.kernel.org/r/20220531215839.84765-1-pablo@netfilter.orgSigned-off-by:
-
Guoju Fang authored
In qdisc_run_end(), the spin_unlock() only has store-release semantic, which guarantees all earlier memory access are visible before it. But the subsequent test_bit() has no barrier semantics so may be reordered ahead of the spin_unlock(). The store-load reordering may cause a packet stuck problem. The concurrent operations can be described as below, CPU 0 | CPU 1 qdisc_run_end() | qdisc_run_begin() . | . ----> /* may be reorderd here */ | . | . | . | spin_unlock() | set_bit() | . | smp_mb__after_atomic() ---- test_bit() | spin_trylock() . | . Consider the following sequence of events: CPU 0 reorder test_bit() ahead and see MISSED = 0 CPU 1 calls set_bit() CPU 1 calls spin_trylock() and return fail CPU 0 executes spin_unlock() At the end of the sequence, CPU 0 calls spin_unlock() and does nothing because it see MISSED = 0. The skb on CPU 1 has beed enqueued but no one take it, until the next cpu pushing to the qdisc (if ever ...) will notice and dequeue it. This patch fix this by adding one explicit barrier. As spin_unlock() and test_bit() ordering is a store-load ordering, a full memory barrier smp_mb() is needed here. Fixes: a90c57f2 ("net: sched: fix packet stuck problem for lockless qdisc") Signed-off-by:Guoju Fang <gjfang@linux.alibaba.com> Link: https://lore.kernel.org/r/20220528101628.120193-1-gjfang@linux.alibaba.comSigned-off-by:
-
- 31 May, 2022 17 commits
-
-
wenxu authored
For snat and dnat cases, the saddr should be taken from reverse tuple. Fixes: 3412e164 (netfilter: flowtable: nft_flow_route use more data for reverse route) Signed-off-by:
wenxu <wenxu@chinatelecom.cn> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
wenxu authored
The nf_flow_table gets route through ip_route_output_key. If the saddr is not local one, then FLOWI_FLAG_ANYSRC flag should be set. Without this flag, the route lookup for other_dst will fail. Fixes: 3412e164 (netfilter: flowtable: nft_flow_route use more data for reverse route) Signed-off-by:
-
Pablo Neira Ayuso authored
__nft_release_hooks() is called from pre_netns exit path which unregisters the hooks, then the NETDEV_UNREGISTER event is triggered which unregisters the hooks again. [ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_unregister_net_hook+0x247/0x270 [...] [ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27 [ 565.253682] Workqueue: netns cleanup_net [ 565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270 [...] [ 565.297120] Call Trace: [ 565.300900] <TASK> [ 565.304683] nf_tables_flowtable_event+0x16a/0x220 [nf_tables] [ 565.308518] raw_notifier_call_chain+0x63/0x80 [ 565.312386] unregister_netdevice_many+0x54f/0xb50 Unregister and destroy netdev hook from netns pre_exit via kfree_rcu so the NETDEV_UNREGISTER path see unregistered hooks. Fixes: 767d1216 ("netfilter: nftables: fix possible UAF over chains from packet path in netns") Signed-off-by:
-
Pablo Neira Ayuso authored
clean_net() runs in workqueue while walking over the lists, grab mutex. Fixes: 767d1216 ("netfilter: nftables: fix possible UAF over chains from packet path in netns") Signed-off-by:
-
Pablo Neira Ayuso authored
Add several sanity checks for nft_set_desc_concat_parse(): - validate desc->field_count not larger than desc->field_len array. - field length cannot be larger than desc->field_len (ie. U8_MAX) - total length of the concatenation cannot be larger than register array. Joint work with Florian Westphal. Fixes: f3a2181e ("netfilter: nf_tables: Support for sets with multiple ranged fields") Reported-by: <zhangziming.zzm@antgroup.com> Reviewed-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Saeed Mahameed authored
In some use-cases, mlx5 instances will need to search for their peer device (the other port on the same HCA). For that, mlx5 device matching mechanism relied on auxiliary_find_device() to search, and used a bad matching callback function. This approach has two issues: 1) next_phys_dev() the matching function, assumed all devices are of the type mlx5_adev (mlx5 auxiliary device) which is wrong and could lead to crashes, this worked for a while, since only lately other drivers started registering auxiliary devices. 2) using the auxiliary class bus (auxiliary_find_device) to search for mlx5_core_dev devices, who are actually PCIe device instances, is wrong. This works since mlx5_core always has at least one mlx5_adev instance hanging around in the aux bus. As suggested by others we can fix 1. by comparing device names prefixes if they have the string "mlx5_core" in them, which is not a best practice ! but even with that fixed, still 2. needs fixing, we are trying to match pcie device peers so we should look in the right bus (pci bus), hence this fix. The fix: 1) search the pci bus for mlx5 peer devices, instead of the aux bus 2) to validated devices are the same type "mlx5_core_dev" compare if they have the same driver, which is bulletproof. This wouldn't have worked with the aux bus since the various mlx5 aux device types don't share the same driver, even if they share the same device wrapper struct (mlx5_adev) "which helped to find the parent device" Fixes: a925b5e3 ("net/mlx5: Register mlx5 devices to auxiliary virtual bus") Reported-by:
Maher Sanalla <msanalla@nvidia.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
Mark Bloch <mbloch@nvidia.com> Reviewed-by:
-
Maxim Mikityanskiy authored
Some features (LRO, HW GRO) conflict with XDP. If there is an attempt to enable such features while XDP is active, they will be set to `off [requested on]`. In order to activate these features after XDP is turned off, the driver needs to call netdev_update_features(). This commit adds this missing call after XDP state changes. Fixes: cf6e34c8 ("net/mlx5e: Properly block LRO when XDP is enabled") Fixes: b0617e7b ("net/mlx5e: Properly block HW GRO when XDP is enabled") Signed-off-by:
Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by:
-
Changcheng Liu authored
ECE field should be after opt_param_mask in query qp output. Fixes: 6b646a7e ("net/mlx5: Add ability to read and write ECE options") Signed-off-by:
Changcheng Liu <jerrliu@nvidia.com> Signed-off-by:
-
Maxim Mikityanskiy authored
When the driver activates the channels, it assumes NAPI isn't running yet. mlx5e_activate_rq posts a NOP WQE to ICOSQ to trigger a hardware interrupt and start NAPI, which will run mlx5e_alloc_rx_mpwqe and post UMR WQEs to ICOSQ to be able to receive packets with striding RQ. Unfortunately, a race condition is possible if NAPI is triggered by something else (for example, TX) at a bad timing, before mlx5e_activate_rq finishes. In this case, mlx5e_alloc_rx_mpwqe may post UMR WQEs to ICOSQ, and with the bad timing, the wqe_info of the first UMR may be overwritten by the wqe_info of the NOP posted by mlx5e_activate_rq. The consequence is that icosq->db.wqe_info[0].num_wqebbs will be changed from MLX5E_UMR_WQEBBS to 1, disrupting the integrity of the array-based linked list in wqe_info[]. mlx5e_poll_ico_cq will hang in an infinite loop after processing wqe_info[0], because after the corruption, the next item to be processed will be wqe_info[1], which is filled with zeros, and `sqcc += wi->num_wqebbs` will never move further. This commit fixes this race condition by using async_icosq to post the NOP and trigger the interrupt. async_icosq is always protected with a spinlock, eliminating the race condition. Fixes: bc77b240 ("net/mlx5e: Add fragmented memory support for RX multi packet WQE") Signed-off-by:
Karsten Nielsen <karsten@foo-bar.dk> Reviewed-by:
-
Paul Blakey authored
Tuple entries that don't have nat configured for them which are added to the ct nat table will always create a new modify header, as we don't check for possible re-use on them. The same for tuples that have nat configured for them but are added to ct table. Fix the above by only avoiding wasteful re-use lookup for actually natted entries in ct nat table. Fixes: 7fac5c2e ("net/mlx5: CT: Avoid reusing modify header context for natted entries") Signed-off-by:
Paul Blakey <paulb@nvidia.com> Reviewed-by:
Ariel Levkovich <lariel@nvidia.com> Signed-off-by:
-
Maor Dickman authored
The cited commit changed promisc table to be created on demand with the highest priority in the NIC table replacing the vlan table, this caused tc NIC tables miss flow to skip the prmoisc table because it use vlan table as miss table. OVS offload in NIC mode use promisc by default so any unicast packet which will be handled by tc NIC tables miss flow will skip the promisc rule and will be dropped. Fix this by adding new empty table in new tc level with low priority and point the nic tc chain miss to it, the new table is managed so it will point to vlan table if promisc is disabled and to promisc table if enabled. Fixes: 1c46d740 ("net/mlx5e: Optimize promiscuous mode") Signed-off-by:
Maor Dickman <maord@nvidia.com> Reviewed-by:
-
Leon Romanovsky authored
The call to mlx5dr_action_destroy() releases "action" memory. That pointer is set to miss_action later and generates the following smatch error: drivers/net/ethernet/mellanox/mlx5/core/steering/fs_dr.c:53 set_miss_action() warn: 'action' was already freed. Make sure that the pointer is always valid by setting NULL after destroy. Fixes: 6a48faee ("net/mlx5: Add direct rule fs_cmd implementation") Reported-by:
-
Juergen Gross authored
Commit 6fac592c ("xen: update ring.h") missed to fix one use case of RING_HAS_UNCONSUMED_REQUESTS(). Reported-by:
Jan Beulich <jbeulich@suse.com> Fixes: 6fac592c ("xen: update ring.h") Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Wei Liu <wei.liu@kernel.org> Link: https://lore.kernel.org/r/20220530113459.20124-1-jgross@suse.comSigned-off-by:
-
Arun Ajith S authored
RFC 9131 changes default behaviour of handling RX of NA messages when the corresponding entry is absent in the neighbour cache. The current implementation is limited to accept just unsolicited NAs. However, the RFC is more generic where it also accepts solicited NAs. Both types should result in adding a STALE entry for this case. Expand accept_untracked_na behaviour to also accept solicited NAs to be compliant with the RFC and rename the sysctl knob to accept_untracked_na. Fixes: f9a2fb73 ("net/ipv6: Introduce accept_unsolicited_na knob to implement router-side changes for RFC9131") Signed-off-by:
Arun Ajith S <aajith@arista.com> Reviewed-by:
-
Hangbin Liu authored
When adding bond new parameter ns_targets. I forgot to print this in bond master proc info. After updating, the bond master info will look like: ARP IP target/s (n.n.n.n form): 192.168.1.254 NS IPv6 target/s (XX::XX form): 2022::1, 2022::2 Fixes: 4e24be01 ("bonding: add new parameter ns_targets") Reported-by:
Li Liang <liali@redhat.com> Signed-off-by:
-
Viorel Suman authored
Before 7beecaf7 ("net: phy: at803x: improve the WOL feature") patch "at803x_get_wol" implementation used AT803X_INTR_ENABLE_WOL value to set WAKE_MAGIC flag, and now AT803X_WOL_EN value is used for the same purpose. The problem here is that the values of these two bits are different after hardware reset: AT803X_INTR_ENABLE_WOL=0 after hardware reset, but AT803X_WOL_EN=1. So now, if called right after boot, "at803x_get_wol" will set WAKE_MAGIC flag, even if WOL function is not enabled by calling "at803x_set_wol" function. The patch disables WOL function on probe thus the behavior is consistent. Fixes: 7beecaf7 ("net: phy: at803x: improve the WOL feature") Signed-off-by:
Viorel Suman <viorel.suman@nxp.com> Link: https://lore.kernel.org/r/20220527084935.235274-1-viorel.suman@oss.nxp.comSigned-off-by:
-
huhai authored
Fix the following build warning when CONFIG_IPV6 is not set: In function ‘fortify_memcpy_chk’, inlined from ‘tcp_md5_do_add’ at net/ipv4/tcp_ipv4.c:1210:2: ./include/linux/fortify-string.h:328:4: 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] 328 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suggested-by:huhai <huhai@kylinos.cn> Reviewed-by:
-
- 30 May, 2022 3 commits
-
-
Ping-Ke Shih authored
The set_tim is supposed to be atomic, but we should download beacon context to firmware with a mutex lock. To avoid warning, do the thing in another work. BUG: scheduling while atomic: swapper/1/0/0x00000700 Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W 5.18.0-rc7-00703-g33b5ee09a0c1 #4 Hardware name: Pine64 RK3566 Quartz64-A Board (DT) Call trace: dump_backtrace.part.0+0xc4/0xd0 show_stack+0x14/0x60 dump_stack_lvl+0x60/0x78 dump_stack+0x14/0x2c __schedule_bug+0x5c/0x70 __schedule+0x5c4/0x630 schedule+0x44/0xb0 schedule_preempt_disabled+0xc/0x14 __mutex_lock.constprop.0+0x538/0x56c __mutex_lock_slowpath+0x10/0x20 mutex_lock+0x54/0x60 rtw_ops_set_tim+0x20/0x40 __sta_info_recalc_tim+0x150/0x250 sta_info_recalc_tim+0x10/0x20 invoke_tx_handlers_early+0x4e4/0x5c0 ieee80211_tx+0x78/0x110 ieee80211_xmit+0x94/0xc0 __ieee80211_subif_start_xmit+0x818/0xd20 ieee80211_subif_start_xmit+0x44/0x2d0 dev_hard_start_xmit+0xd0/0x150 __dev_queue_xmit+0x250/0xb30 dev_queue_xmit+0x10/0x20 br_dev_queue_push_xmit+0x94/0x174 br_forward_finish+0x90/0xa0 __br_forward+0xc0/0x13c br_forward+0x108/0x134 br_dev_xmit+0x1cc/0x3a4 dev_hard_start_xmit+0xd0/0x150 __dev_queue_xmit+0x250/0xb30 dev_queue_xmit+0x10/0x20 arp_xmit+0x6c/0x7c arp_send_dst+0x8c/0xc0 arp_solicit+0xd4/0x1e0 neigh_probe+0x58/0xa0 neigh_timer_handler+0x27c/0x380 call_timer_fn.constprop.0+0x20/0x80 __run_timers.part.0+0x230/0x280 run_timer_softirq+0x38/0x70 _stext+0x104/0x278 __irq_exit_rcu+0xa4/0xdc irq_exit_rcu+0xc/0x14 el1_interrupt+0x34/0x50 el1h_64_irq_handler+0x14/0x20 el1h_64_irq+0x64/0x68 arch_cpu_idle+0x14/0x20 do_idle+0x208/0x290 cpu_startup_entry+0x20/0x30 secondary_start_kernel+0x130/0x144 __secondary_switched+0x54/0x58 Fixes: f2217968 ("rtw88: Add update beacon flow for AP mode") Reported-by:
Ondřej Jirman <megi@xff.cz> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Tested-by:
-
Johannes Berg authored
At least mips64 has ist own CAUSE macro, so rename ours to IWL_CAUSE to fix build issues. Reported-by:
Gregory Greenman <gregory.greenman@intel.com> Signed-off-by:
-
Johannes Berg authored
The firmware has a 512 limit here, but we use less, so gcc starts complaining about it: drivers/net/wireless/marvell/libertas/cfg.c:1198:63: warning: array subscript ‘struct cmd_ds_802_11_associate_response[0]’ is partly outside array bounds of ‘unsigned char[203]’ [-Warray-bounds] 1198 | "aid 0x%04x\n", status, le16_to_cpu(resp->statuscode), | ^~ Since we size the command and response buffer per our needs and not per the firmware maximum, change to a variable size data array and put the 512 only into a comment. In the end, that's actually what the code always wanted, and it simplifies the code that used to subtract the fixed size buffer size in two places. Reported-by:
-
