- 23 Nov, 2022 20 commits
-
-
Yuan Can authored
The iavf_init_module() won't destroy workqueue when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002 ("usb: u132-hcd: fix resource leak") Fixes: 2803b16c ("i40e/i40evf: Use private workqueue") Signed-off-by:
Yuan Can <yuancan@huawei.com> Tested-by:
Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Yuan Can authored
A problem about modprobe fm10k failed is triggered with the following log given: Intel(R) Ethernet Switch Host Interface Driver Copyright(c) 2013 - 2019 Intel Corporation. debugfs: Directory 'fm10k' with parent '/' already present! The reason is that fm10k_init_module() returns fm10k_register_pci_driver() directly without checking its return value, if fm10k_register_pci_driver() failed, it returns without removing debugfs and destroy workqueue, resulting the debugfs of fm10k can never be created later and leaks the workqueue. fm10k_init_module() alloc_workqueue() fm10k_dbg_init() # create debugfs fm10k_register_pci_driver() pci_register_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without remove debugfs and destroy workqueue Fix by remove debugfs and destroy workqueue when fm10k_register_pci_driver() returns error. Fixes: 7461fd91 ("fm10k: Add support for debugfs") Fixes: b382bb1b ("fm10k: use separate workqueue for fm10k driver") Signed-off-by:Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Shang XiaoJing authored
i40e_init_module() won't free the debugfs directory created by i40e_dbg_init() when pci_register_driver() failed. Add fail path to call i40e_dbg_exit() to remove the debugfs entries to prevent the bug. i40e: Intel(R) Ethernet Connection XL710 Network Driver i40e: Copyright (c) 2013 - 2019 Intel Corporation. debugfs: Directory 'i40e' with parent '/' already present! Fixes: 41c445ff ("i40e: main driver core") Signed-off-by:
Shang XiaoJing <shangxiaojing@huawei.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by:
-
Shang XiaoJing authored
ixgbevf_init_module() won't destroy the workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Add destroy_workqueue() in fail path to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002 ("usb: u132-hcd: fix resource leak") Fixes: 40a13e24 ("ixgbevf: Use a private workqueue to avoid certain possible hangs") Signed-off-by:
Saeed Mahameed <saeed@kernel.org> Tested-by:
-
Santiago Ruano Rincón authored
ZLP for DisplayLink ethernet devices was enabled in 6.0: 266c0190 ("net/cdc_ncm: Enable ZLP for DisplayLink ethernet devices"). The related driver_info should be the "same as cdc_ncm_info, but with FLAG_SEND_ZLP". However, set_rx_mode that enables handling multicast traffic was missing in the new cdc_ncm_zlp_info. usbnet_cdc_update_filter rx mode was introduced in linux 5.9 with: e10dcb1b ("net: cdc_ncm: hook into set_rx_mode to admit multicast traffic") Without this hook, multicast, and then IPv6 SLAAC, is broken. Fixes: 266c0190 ("net/cdc_ncm: Enable ZLP for DisplayLink ethernet devices") Signed-off-by:
Santiago Ruano Rincón <santiago.ruano-rincon@imt-atlantique.fr> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Davide Tronchin authored
Add RmNet support for LARA-L6. LARA-L6 module can be configured (by AT interface) in three different USB modes: * Default mode (Vendor ID: 0x1546 Product ID: 0x1341) with 4 serial interfaces * RmNet mode (Vendor ID: 0x1546 Product ID: 0x1342) with 4 serial interfaces and 1 RmNet virtual network interface * CDC-ECM mode (Vendor ID: 0x1546 Product ID: 0x1343) with 4 serial interface and 1 CDC-ECM virtual network interface In RmNet mode LARA-L6 exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parset/alternative functions If 4: RMNET interface Signed-off-by:
Davide Tronchin <davide.tronchin.94@gmail.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Jakub Sitnicki authored
When holding a reader-writer spin lock we cannot sleep. Calling setup_udp_tunnel_sock() with write lock held violates this rule, because we end up calling percpu_down_read(), which might sleep, as syzbot reports [1]: __might_resched.cold+0x222/0x26b kernel/sched/core.c:9890 percpu_down_read include/linux/percpu-rwsem.h:49 [inline] cpus_read_lock+0x1b/0x140 kernel/cpu.c:310 static_key_slow_inc+0x12/0x20 kernel/jump_label.c:158 udp_tunnel_encap_enable include/net/udp_tunnel.h:187 [inline] setup_udp_tunnel_sock+0x43d/0x550 net/ipv4/udp_tunnel_core.c:81 l2tp_tunnel_register+0xc51/0x1210 net/l2tp/l2tp_core.c:1509 pppol2tp_connect+0xcdc/0x1a10 net/l2tp/l2tp_ppp.c:723 Trim the writer-side critical section for sk_callback_lock down to the minimum, so that it covers only operations on sk_user_data. Also, when grabbing the sk_callback_lock, we always need to disable BH, as Eric points out. Failing to do so leads to deadlocks because we acquire sk_callback_lock in softirq context, which can get stuck waiting on us if: 1) it runs on the same CPU, or CPU0 ---- lock(clock-AF_INET6); <Interrupt> lock(clock-AF_INET6); 2) lock ordering leads to priority inversion CPU0 CPU1 ---- ---- lock(clock-AF_INET6); local_irq_disable(); lock(&tcp_hashinfo.bhash[i].lock); lock(clock-AF_INET6); <Interrupt> lock(&tcp_hashinfo.bhash[i].lock); ... as syzbot reports [2,3]. Use the _bh variants for write_(un)lock. [1] https://lore.kernel.org/netdev/0000000000004e78ec05eda79749@google.com/ [2] https://lore.kernel.org/netdev/000000000000e38b6605eda76f98@google.com/ [3] https://lore.kernel.org/netdev/000000000000dfa31e05eda76f75@google.com/ v2: - Check and set sk_user_data while holding sk_callback_lock for both L2TP encapsulation types (IP and UDP) (Tetsuo) Cc: Tom Parkin <tparkin@katalix.com> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Fixes: b68777d5 ("l2tp: Serialize access to sk_user_data with sk_callback_lock") Reported-by:Eric Dumazet <edumazet@google.com> Reported-by: syzbot+703d9e154b3b58277261@syzkaller.appspotmail.com Reported-by: syzbot+50680ced9e98a61f7698@syzkaller.appspotmail.com Reported-by: syzbot+de987172bb74a381879b@syzkaller.appspotmail.com Signed-off-by:
Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by:
-
Yuan Can authored
The dm9051_loop_rx() returns without release skb when dm9051_stop_mrcmd() returns error, free the skb to avoid this leak. Fixes: 2dc95a4d ("net: Add dm9051 driver") Signed-off-by:
Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by:
-
Wang Hai authored
In com20020_probe(), if com20020_config() fails, dev and info will not be freed, which will lead to a memory leak. This patch adds freeing dev and info after com20020_config() fails to fix this bug. Compile tested only. Fixes: 15b99ac1 ("[PATCH] pcmcia: add return value to _config() functions") Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== mlx5 fixes 2022-11-21 This series provides bug fixes to mlx5 driver. * tag 'mlx5-fixes-2022-11-21' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5e: Fix possible race condition in macsec extended packet number update routine net/mlx5e: Fix MACsec update SecY net/mlx5e: Fix MACsec SA initialization routine net/mlx5e: Remove leftovers from old XSK queues enumeration net/mlx5e: Offload rule only when all encaps are valid net/mlx5e: Fix missing alignment in size of MTT/KLM entries net/mlx5: Fix sync reset event handler error flow net/mlx5: E-Switch, Set correctly vport destination net/mlx5: Lag, avoid lockdep warnings net/mlx5: Fix handling of entry refcount when command is not issued to FW net/mlx5: cmdif, Print info on any firmware cmd failure to tracepoint net/mlx5: SF: Fix probing active SFs during driver probe phase net/mlx5: Fix FW tracer timestamp calculation net/mlx5: Do not query pci info while pci disabled ==================== Link: https://lore.kernel.org/r/20221122022559.89459-1-saeed@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ziyang Xuan authored
In fib_table_insert(), if the alias was already inserted, but node not exist, the error code should be set before return from error handling path. Fixes: a6c76c17 ("ipv4: Notify route after insertion to the routing table") Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Link: https://lore.kernel.org/r/20221120072838.2167047-1-william.xuanziyang@huawei.comSigned-off-by:
-
Jakub Kicinski authored
Yan Cangang says: ==================== net: ethernet: mtk_eth_soc: fix memory leak in error path ==================== Link: https://lore.kernel.org/r/20221120055259.224555-1-nalanzeyu@gmail.comSigned-off-by:
-
Yan Cangang authored
In mtk_ppe_init(), when dmam_alloc_coherent() or devm_kzalloc() failed, the rhashtable ppe->l2_flows isn't destroyed. Fix it. In mtk_probe(), when mtk_ppe_init() or mtk_eth_offload_init() or register_netdev() failed, have the same problem. Fix it. Fixes: 33fc42de ("net: ethernet: mtk_eth_soc: support creating mac address based offload entries") Signed-off-by:
Yan Cangang <nalanzeyu@gmail.com> Reviewed-by:
-
Yan Cangang authored
In mtk_probe(), when mtk_ppe_init() or mtk_eth_offload_init() failed, mtk_mdio_cleanup() isn't called. Fix it. Fixes: ba37b7ca ("net: ethernet: mtk_eth_soc: add support for initializing the PPE") Fixes: 502e84e2 ("net: ethernet: mtk_eth_soc: add flow offloading support") Signed-off-by:
-
Ziyang Xuan authored
When fail to dma_map_single() in mtk_rx_alloc(), it returns directly. But the memory allocated for local variable data is not freed, and local variabel data has not been attached to ring->data[i] yet, so the memory allocated for local variable data will not be freed outside mtk_rx_alloc() too. Thus memory leak would occur in this scenario. Add skb_free_frag(data) when dma_map_single() failed. Fixes: 23233e57 ("net: ethernet: mtk_eth_soc: rely on page_pool for single page buffers") Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Link: https://lore.kernel.org/r/20221120035405.1464341-1-william.xuanziyang@huawei.comSigned-off-by:
-
Jakub Kicinski authored
Kuniyuki Iwashima says: ==================== dccp/tcp: Fix bhash2 issues related to WARN_ON() in inet_csk_get_port(). syzkaller was hitting a WARN_ON() in inet_csk_get_port() in the 4th patch, which was because we forgot to fix up bhash2 bucket when connect() for a socket bound to a wildcard address fails in __inet_stream_connect(). There was a similar report [0], but its repro does not fire the WARN_ON() due to inconsistent error handling. When connect() for a socket bound to a wildcard address fails, saddr may or may not be reset depending on where the failure happens. When we fail in __inet_stream_connect(), sk->sk_prot->disconnect() resets saddr. OTOH, in (dccp|tcp)_v[46]_connect(), if we fail after inet_hash6?_connect(), we forget to reset saddr. We fix this inconsistent error handling in the 1st patch, and then we'll fix the bhash2 WARN_ON() issue. Note that there is still an issue in that we reset saddr without checking if there are conflicting sockets in bhash and bhash2, but this should be another series. See [1][2] for the previous discussion. [0]: https://lore.kernel.org/netdev/0000000000003f33bc05dfaf44fe@google.com/ [1]: https://lore.kernel.org/netdev/20221029001249.86337-1-kuniyu@amazon.com/ [2]: https://lore.kernel.org/netdev/20221103172419.20977-1-kuniyu@amazon.com/ [3]: https://lore.kernel.org/netdev/20221118081906.053d5231@kernel.org/T/#m00aafedb29ff0b55d5e67aef0252ef1baaf4b6ee ==================== Link: https://lore.kernel.org/r/20221119014914.31792-1-kuniyu@amazon.comSigned-off-by:
-
Kuniyuki Iwashima authored
If a socket bound to a wildcard address fails to connect(), we only reset saddr and keep the port. Then, we have to fix up the bhash2 bucket; otherwise, the bucket has an inconsistent address in the list. Also, listen() for such a socket will fire the WARN_ON() in inet_csk_get_port(). [0] Note that when a system runs out of memory, we give up fixing the bucket and unlink sk from bhash and bhash2 by inet_put_port(). [0]: WARNING: CPU: 0 PID: 207 at net/ipv4/inet_connection_sock.c:548 inet_csk_get_port (net/ipv4/inet_connection_sock.c:548 (discriminator 1)) Modules linked in: CPU: 0 PID: 207 Comm: bhash2_prev_rep Not tainted 6.1.0-rc3-00799-gc8421681c845 #63 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014 RIP: 0010:inet_csk_get_port (net/ipv4/inet_connection_sock.c:548 (discriminator 1)) Code: 74 a7 eb 93 48 8b 54 24 18 0f b7 cb 4c 89 e6 4c 89 ff e8 48 b2 ff ff 49 8b 87 18 04 00 00 e9 32 ff ff ff 0f 0b e9 34 ff ff ff <0f> 0b e9 42 ff ff ff 41 8b 7f 50 41 8b 4f 54 89 fe 81 f6 00 00 ff RSP: 0018:ffffc900003d7e50 EFLAGS: 00010202 RAX: ffff8881047fb500 RBX: 0000000000004e20 RCX: 0000000000000000 RDX: 000000000000000a RSI: 00000000fffffe00 RDI: 00000000ffffffff RBP: ffffffff8324dc00 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000004e20 R15: ffff8881054e1280 FS: 00007f8ac04dc740(0000) GS:ffff88842fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020001540 CR3: 00000001055fa003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> inet_csk_listen_start (net/ipv4/inet_connection_sock.c:1205) inet_listen (net/ipv4/af_inet.c:228) __sys_listen (net/socket.c:1810) __x64_sys_listen (net/socket.c:1819 net/socket.c:1817 net/socket.c:1817) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) RIP: 0033:0x7f8ac051de5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 93 af 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007ffc1c177248 EFLAGS: 00000206 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 0000000020001550 RCX: 00007f8ac051de5d RDX: ffffffffffffff80 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00007ffc1c177270 R08: 0000000000000018 R09: 0000000000000007 R10: 0000000020001540 R11: 0000000000000206 R12: 00007ffc1c177388 R13: 0000000000401169 R14: 0000000000403e18 R15: 00007f8ac0723000 </TASK> Fixes: 28044fc1 ("net: Add a bhash2 table hashed by port and address") Reported-by:
syzbot <syzkaller@googlegroups.com> Reported-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Acked-by:
Joanne Koong <joannelkoong@gmail.com> Reviewed-by:
-
Kuniyuki Iwashima authored
When we call connect() for a socket bound to a wildcard address, we update saddr locklessly. However, it could result in a data race; another thread iterating over bhash might see a corrupted address. Let's update saddr under the bhash bucket's lock. Fixes: 3df80d93 ("[DCCP]: Introduce DCCPv6") Fixes: 7c657876 ("[DCCP]: Initial implementation") Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Kuniyuki Iwashima authored
When we call inet_bhash2_update_saddr(), prev_saddr is always non-NULL. Let's remove the unnecessary test. Signed-off-by:
-
Kuniyuki Iwashima authored
When connect() is called on a socket bound to the wildcard address, we change the socket's saddr to a local address. If the socket fails to connect() to the destination, we have to reset the saddr. However, when an error occurs after inet_hash6?_connect() in (dccp|tcp)_v[46]_conect(), we forget to reset saddr and leave the socket bound to the address. From the user's point of view, whether saddr is reset or not varies with errno. Let's fix this inconsistent behaviour. Note that after this patch, the repro [0] will trigger the WARN_ON() in inet_csk_get_port() again, but this patch is not buggy and rather fixes a bug papering over the bhash2's bug for which we need another fix. For the record, the repro causes -EADDRNOTAVAIL in inet_hash6_connect() by this sequence: s1 = socket() s1.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) s1.bind(('127.0.0.1', 10000)) s1.sendto(b'hello', MSG_FASTOPEN, (('127.0.0.1', 10000))) # or s1.connect(('127.0.0.1', 10000)) s2 = socket() s2.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) s2.bind(('0.0.0.0', 10000)) s2.connect(('127.0.0.1', 10000)) # -EADDRNOTAVAIL s2.listen(32) # WARN_ON(inet_csk(sk)->icsk_bind2_hash != tb2); [0]: https://syzkaller.appspot.com/bug?extid=015d756bbd1f8b5c8f09 Fixes: 3df80d93 ("[DCCP]: Introduce DCCPv6") Fixes: 7c657876 ("[DCCP]: Initial implementation") Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
- 22 Nov, 2022 20 commits
-
-
Gerhard Engleder authored
If PTP synchronisation is done every second, then sporadic the interval is higher than one second: ptp4l[696.582]: master offset -17 s2 freq -1891 path delay 573 ptp4l[697.582]: master offset -22 s2 freq -1901 path delay 573 ptp4l[699.368]: master offset -1 s2 freq -1887 path delay 573 ^^^^^^^ Should be 698.582! This problem is caused by rotten packets, which are received after polling but before interrupts are enabled again. This can be fixed by checking for pending work and rescheduling if necessary after interrupts has been enabled again. Fixes: 403f69bb ("tsnep: Add TSN endpoint Ethernet MAC driver") Signed-off-by:Gerhard Engleder <gerhard@engleder-embedded.com> Link: https://lore.kernel.org/r/20221119211825.81805-1-gerhard@engleder-embedded.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Zheng Bin authored
Commit 4581dd48 ("net: octeontx2-pf: mcs: consider MACSEC setting") has already added "depends on MACSEC || !MACSEC", so remove it. Signed-off-by:
Zheng Bin <zhengbin13@huawei.com> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20221119133616.3583538-1-zhengbin13@huawei.comSigned-off-by:
-
Yang Yingliang authored
As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). Call pci_dev_put() before returning from bnx2x_vf_is_pcie_pending() to avoid refcount leak. Fixes: b56e9670 ("bnx2x: Prepare device and initialize VF database") Suggested-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
-
Liu Shixin authored
Syzbot reported a memory leak about skb: unreferenced object 0xffff88810e144e00 (size 240): comm "syz-executor284", pid 3701, jiffies 4294952403 (age 12.620s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff83ab79a9>] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:497 [<ffffffff82a5cf64>] alloc_skb include/linux/skbuff.h:1267 [inline] [<ffffffff82a5cf64>] virtual_ncidev_write+0x24/0xe0 drivers/nfc/virtual_ncidev.c:116 [<ffffffff815f6503>] do_loop_readv_writev fs/read_write.c:759 [inline] [<ffffffff815f6503>] do_loop_readv_writev fs/read_write.c:743 [inline] [<ffffffff815f6503>] do_iter_write+0x253/0x300 fs/read_write.c:863 [<ffffffff815f66ed>] vfs_writev+0xdd/0x240 fs/read_write.c:934 [<ffffffff815f68f6>] do_writev+0xa6/0x1c0 fs/read_write.c:977 [<ffffffff848802d5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff848802d5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84a00087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd In nci_rx_data_packet(), if we don't get a valid conn_info, we will return directly but forget to release the skb. Reported-by: syzbot+cdb9a427d1bc08815104@syzkaller.appspotmail.com Fixes: 4aeee687 ("NFC: nci: Add dynamic logical connections support") Signed-off-by:Liu Shixin <liushixin2@huawei.com> Link: https://lore.kernel.org/r/20221118082419.239475-1-liushixin2@huawei.comSigned-off-by:
-
Xin Long authored
In commit f11fe1da ("net/sched: Make NET_ACT_CT depends on NF_NAT"), it fixed the build failure when NF_NAT is m and NET_ACT_CT is y by adding depends on NF_NAT for NET_ACT_CT. However, it would also cause NET_ACT_CT cannot be built without NF_NAT, which is not expected. This patch fixes it by changing to use "(!NF_NAT || NF_NAT)" as the depend. Fixes: f11fe1da ("net/sched: Make NET_ACT_CT depends on NF_NAT") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/b6386f28d1ba34721795fb776a91cbdabb203447.1668807183.git.lucien.xin@gmail.comSigned-off-by:
-
Liu Jian authored
If phylink_of_phy_connect() fails, the port should be disabled. If sparx5_serdes_set()/phy_power_on() fails, the port should be disabled and the phylink should be stopped and disconnected. Fixes: 946e7fd5 ("net: sparx5: add port module support") Fixes: f3cad261 ("net: sparx5: add hostmode with phylink support") Signed-off-by:
Liu Jian <liujian56@huawei.com> Tested-by:
Bjarni Jonasson <bjarni.jonasson@microchip.com> Reviewed-by:
Steen Hegelund <steen.hegelund@microchip.com> Link: https://lore.kernel.org/r/20221117125918.203997-1-liujian56@huawei.comSigned-off-by:
-
Zhang Changzhong authored
The __ef100_hard_start_xmit() returns NETDEV_TX_OK without freeing skb in error handling case, add dev_kfree_skb_any() to fix it. Fixes: 51b35a45 ("sfc: skeleton EF100 PF driver") Signed-off-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by:
Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by:
-
Wang ShaoBo authored
acpi_evaluate_dsm() should be coupled with ACPI_FREE() to free the ACPI memory, because we need to track the allocation of acpi_object when ACPI_DBG_TRACK_ALLOCATIONS enabled, so use ACPI_FREE() instead of kfree(). Fixes: d38a648d ("net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg") Signed-off-by:
Wang ShaoBo <bobo.shaobowang@huawei.com> Link: https://lore.kernel.org/r/20221118062447.2324881-1-bobo.shaobowang@huawei.comSigned-off-by:
-
Jacob Keller authored
Commit 1229b339 ("ice: Add low latency Tx timestamp read") refactored PTP timestamping logic to use a threaded IRQ instead of a separate kthread. This implementation introduced ice_misc_intr_thread_fn and redefined the ice_ptp_process_ts function interface to return a value of whether or not the timestamp processing was complete. ice_misc_intr_thread_fn would take the return value from ice_ptp_process_ts and convert it into either IRQ_HANDLED if there were no more timestamps to be processed, or IRQ_WAKE_THREAD if the thread should continue processing. This is not correct, as the kernel does not re-schedule threaded IRQ functions automatically. IRQ_WAKE_THREAD can only be used by the main IRQ function. This results in the ice_ptp_process_ts function (and in turn the ice_ptp_tx_tstamp function) from only being called exactly once per interrupt. If an application sends a burst of Tx timestamps without waiting for a response, the interrupt will trigger for the first timestamp. However, later timestamps may not have arrived yet. This can result in dropped or discarded timestamps. Worse, on E822 hardware this results in the interrupt logic getting stuck such that no future interrupts will be triggered. The result is complete loss of Tx timestamp functionality. Fix this by modifying the ice_misc_intr_thread_fn to perform its own polling of the ice_ptp_process_ts function. We sleep for a few microseconds between attempts to avoid wasting significant CPU time. The value was chosen to allow time for the Tx timestamps to complete without wasting so much time that we overrun application wait budgets in the worst case. The ice_ptp_process_ts function also currently returns false in the event that the Tx tracker is not initialized. This would result in the threaded IRQ handler never exiting if it gets started while the tracker is not initialized. Fix the function to appropriately return true when the tracker is not initialized. Note that this will not reproduce with default ptp4l behavior, as the program always synchronously waits for a timestamp response before sending another timestamp request. Reported-by:
Siddaraju DH <siddaraju.dh@intel.com> Fixes: 1229b339 ("ice: Add low latency Tx timestamp read") Signed-off-by:
-
YueHaibing authored
If skb_linearize() fails in tipc_disc_rcv(), we need to free the skb instead of handle it. Fixes: 25b0b9c4 ("tipc: handle collisions of 32-bit node address hash values") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Jon Maloy <jmaloy@redhat.com> Link: https://lore.kernel.org/r/20221119072832.7896-1-yuehaibing@huawei.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-11-18 (iavf) Ivan Vecera resolves issues related to reset by adding back call to netif_tx_stop_all_queues() and adding calls to dev_close() to ensure device is properly closed during reset. Stefan Assmann removes waiting for setting of MAC address as this breaks ARP. Slawomir adds setting of __IAVF_IN_REMOVE_TASK bit to prevent deadlock between remove and shutdown. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: iavf: Fix race condition between iavf_shutdown and iavf_remove iavf: remove INITIAL_MAC_SET to allow gARP to work properly iavf: Do not restart Tx queues after reset task failure iavf: Fix a crash during reset task ==================== Link: https://lore.kernel.org/r/20221118222439.1565245-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Jakub Kicinski authored
Xin Long says: ==================== tipc: fix two race issues in tipc_conn_alloc The race exists beteen tipc_topsrv_accept() and tipc_conn_close(), one is allocating the con while the other is freeing it and there is no proper lock protecting it. Therefore, a null-pointer-defer and a use-after-free may be triggered, see details on each patch. ==================== Link: https://lore.kernel.org/r/cover.1668807842.git.lucien.xin@gmail.comSigned-off-by:
-
Xin Long authored
One extra conn_get() is needed in tipc_conn_alloc(), as after tipc_conn_alloc() is called, tipc_conn_close() may free this con before deferencing it in tipc_topsrv_accept(): tipc_conn_alloc(); newsk = newsock->sk; <---- tipc_conn_close(); write_lock_bh(&sk->sk_callback_lock); newsk->sk_data_ready = tipc_conn_data_ready; Then an uaf issue can be triggered: BUG: KASAN: use-after-free in tipc_topsrv_accept+0x1e7/0x370 [tipc] Call Trace: <TASK> dump_stack_lvl+0x33/0x46 print_report+0x178/0x4b0 kasan_report+0x8c/0x100 kasan_check_range+0x179/0x1e0 tipc_topsrv_accept+0x1e7/0x370 [tipc] process_one_work+0x6a3/0x1030 worker_thread+0x8a/0xdf0 This patch fixes it by holding it in tipc_conn_alloc(), then after all accessing in tipc_topsrv_accept() releasing it. Note when does this in tipc_topsrv_kern_subscr(), as tipc_conn_rcv_sub() returns 0 or -1 only, we don't need to check for "> 0". Fixes: c5fa7b3c ("tipc: introduce new TIPC server infrastructure") Signed-off-by: -
Xin Long authored
A crash was reported by Wei Chen: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:tipc_conn_close+0x12/0x100 Call Trace: tipc_topsrv_exit_net+0x139/0x320 ops_exit_list.isra.9+0x49/0x80 cleanup_net+0x31a/0x540 process_one_work+0x3fa/0x9f0 worker_thread+0x42/0x5c0 It was caused by !con->sock in tipc_conn_close(). In tipc_topsrv_accept(), con is allocated in conn_idr then its sock is set: con = tipc_conn_alloc(); ... <----[1] con->sock = newsock; If tipc_conn_close() is called in anytime of [1], the null-pointer-def is triggered by con->sock->sk due to con->sock is not yet set. This patch fixes it by moving the con->sock setting to tipc_conn_alloc() under s->idr_lock. So that con->sock can never be NULL when getting the con from s->conn_idr. It will be also safer to move con->server and flag CF_CONNECTED setting under s->idr_lock, as they should all be set before tipc_conn_alloc() is called. Fixes: c5fa7b3c ("tipc: introduce new TIPC server infrastructure") Reported-by:
Wei Chen <harperchen1110@gmail.com> Signed-off-by:
-
Wei Yongjun authored
Fix to return a negative error code from the ccr read error handling case instead of 0, as done elsewhere in this function. Fixes: 3265f421 ("net: phy: at803x: add fiber support") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20221118103635.254256-1-weiyongjun@huaweicloud.comSigned-off-by:
-
Emeel Hakim authored
Currenty extended packet number (EPN) update routine is accessing macsec object without holding the general macsec lock hence facing a possible race condition when an EPN update occurs while updating or deleting the SA. Fix by holding the general macsec lock before accessing the object. Fixes: 4411a6c0 ("net/mlx5e: Support MACsec offload extended packet number (EPN)") Signed-off-by:
Emeel Hakim <ehakim@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Emeel Hakim authored
Currently updating SecY destroys and re-creates RX SA objects, the re-created RX SA objects are not identical to the destroyed objects and it disagree on the encryption enabled property which holds the value false after recreation, this value is not supported with offload which leads to no traffic after an update. Fix by recreating an identical objects. Fixes: 5a39816a ("net/mlx5e: Add MACsec offload SecY support") Signed-off-by:
Raed Salem <raeds@nvidia.com> Signed-off-by:
-
Emeel Hakim authored
Currently as part of MACsec SA initialization routine extended packet number (EPN) object attribute is always being set without checking if EPN is actually enabled, the above could lead to a NULL dereference. Fix by adding such a check. Fixes: 4411a6c0 ("net/mlx5e: Support MACsec offload extended packet number (EPN)") Signed-off-by:
-
Tariq Toukan authored
Before the cited commit, for N channels, a dedicated set of N queues was created to support XSK, in indices [N, 2N-1], doubling the number of queues. In addition, changing the number of channels was prohibited, as it would shift the indices. Remove these two leftovers, as we moved XSK to a new queueing scheme, starting from index 0. Fixes: 3db4c85c ("net/mlx5e: xsk: Use queue indices starting from 0 for XSK queues") Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Gal Pressman <gal@nvidia.com> Signed-off-by:
-
Chris Mi authored
The cited commit adds a for loop to support multiple encapsulations. But it only checks if the last encap is valid. Fix it by setting slow path flag when one of the encap is invalid. Fixes: f493f155 ("net/mlx5e: Move flow attr reformat action bit to per dest flags") Signed-off-by:
Chris Mi <cmi@nvidia.com> Reviewed-by:
Roi Dayan <roid@nvidia.com> Signed-off-by:
-
