1. 30 Sep, 2021 1 commit
    • Paolo Abeni's avatar
      net: introduce and use lock_sock_fast_nested() · 49054556
      Paolo Abeni authored
      Syzkaller reported a false positive deadlock involving
      the nl socket lock and the subflow socket lock:
      
      MPTCP: kernel_bind error, err=-98
      ============================================
      WARNING: possible recursive locking detected
      5.15.0-rc1-syzkaller #0 Not tainted
      --------------------------------------------
      syz-executor998/6520 is trying to acquire lock:
      ffff8880795718a0 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close+0x267/0x7b0 net/mptcp/protocol.c:2738
      
      but task is already holding lock:
      ffff8880787c8c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1612 [inline]
      ffff8880787c8c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close+0x23/0x7b0 net/mptcp/protocol.c:2720
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(k-sk_lock-AF_INET);
        lock(k-sk_lock-AF_INET);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      3 locks held by syz-executor998/6520:
       #0: ffffffff8d176c50 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 net/netlink/genetlink.c:802
       #1: ffffffff8d176d08 (genl_mutex){+.+.}-{3:3}, at: genl_lock net/netlink/genetlink.c:33 [inline]
       #1: ffffffff8d176d08 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg+0x3e0/0x580 net/netlink/genetlink.c:790
       #2: ffff8880787c8c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1612 [inline]
       #2: ffff8880787c8c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close+0x23/0x7b0 net/mptcp/protocol.c:2720
      
      stack backtrace:
      CPU: 1 PID: 6520 Comm: syz-executor998 Not tainted 5.15.0-rc1-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
       print_deadlock_bug kernel/locking/lockdep.c:2944 [inline]
       check_deadlock kernel/locking/lockdep.c:2987 [inline]
       validate_chain kernel/locking/lockdep.c:3776 [inline]
       __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5015
       lock_acquire kernel/locking/lockdep.c:5625 [inline]
       lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5590
       lock_sock_fast+0x36/0x100 net/core/sock.c:3229
       mptcp_close+0x267/0x7b0 net/mptcp/protocol.c:2738
       inet_release+0x12e/0x280 net/ipv4/af_inet.c:431
       __sock_release net/socket.c:649 [inline]
       sock_release+0x87/0x1b0 net/socket.c:677
       mptcp_pm_nl_create_listen_socket+0x238/0x2c0 net/mptcp/pm_netlink.c:900
       mptcp_nl_cmd_add_addr+0x359/0x930 net/mptcp/pm_netlink.c:1170
       genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:731
       genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
       genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:792
       netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
       genl_rcv+0x24/0x40 net/netlink/genetlink.c:803
       netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
       netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
       netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929
       sock_sendmsg_nosec net/socket.c:704 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:724
       sock_no_sendpage+0x101/0x150 net/core/sock.c:2980
       kernel_sendpage.part.0+0x1a0/0x340 net/socket.c:3504
       kernel_sendpage net/socket.c:3501 [inline]
       sock_sendpage+0xe5/0x140 net/socket.c:1003
       pipe_to_sendpage+0x2ad/0x380 fs/splice.c:364
       splice_from_pipe_feed fs/splice.c:418 [inline]
       __splice_from_pipe+0x43e/0x8a0 fs/splice.c:562
       splice_from_pipe fs/splice.c:597 [inline]
       generic_splice_sendpage+0xd4/0x140 fs/splice.c:746
       do_splice_from fs/splice.c:767 [inline]
       direct_splice_actor+0x110/0x180 fs/splice.c:936
       splice_direct_to_actor+0x34b/0x8c0 fs/splice.c:891
       do_splice_direct+0x1b3/0x280 fs/splice.c:979
       do_sendfile+0xae9/0x1240 fs/read_write.c:1249
       __do_sys_sendfile64 fs/read_write.c:1314 [inline]
       __se_sys_sendfile64 fs/read_write.c:1300 [inline]
       __x64_sys_sendfile64+0x1cc/0x210 fs/read_write.c:1300
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x7f215cb69969
      Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 14 00 00 90 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 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007ffc96bb3868 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
      RAX: ffffffffffffffda RBX: 00007f215cbad072 RCX: 00007f215cb69969
      RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000005
      RBP: 0000000000000000 R08: 00007ffc96bb3a08 R09: 00007ffc96bb3a08
      R10: 0000000100000002 R11: 0000000000000246 R12: 00007ffc96bb387c
      R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000
      
      the problem originates from uncorrect lock annotation in the mptcp
      code and is only visible since commit 2dcb96ba ("net: core: Correct
      the sock::sk_lock.owned lockdep annotations"), but is present since
      the port-based endpoint support initial implementation.
      
      This patch addresses the issue introducing a nested variant of
      lock_sock_fast() and using it in the relevant code path.
      
      Fixes: 1729cf18 ("mptcp: create the listening socket for new port")
      Fixes: 2dcb96ba ("net: core: Correct the sock::sk_lock.owned lockdep annotations")
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reported-and-tested-by: syzbot+1dd53f7a89b299d59eaf@syzkaller.appspotmail.com
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49054556
  2. 29 Sep, 2021 13 commits
    • Florian Fainelli's avatar
      net: phy: bcm7xxx: Fixed indirect MMD operations · d88fd1b5
      Florian Fainelli authored
      When EEE support was added to the 28nm EPHY it was assumed that it would
      be able to support the standard clause 45 over clause 22 register access
      method. It turns out that the PHY does not support that, which is the
      very reason for using the indirect shadow mode 2 bank 3 access method.
      
      Implement {read,write}_mmd to allow the standard PHY library routines
      pertaining to EEE querying and configuration to work correctly on these
      PHYs. This forces us to implement a __phy_set_clr_bits() function that
      does not grab the MDIO bus lock since the PHY driver's {read,write}_mmd
      functions are always called with that lock held.
      
      Fixes: 83ee102a ("net: phy: bcm7xxx: add support for 28nm EPHY")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d88fd1b5
    • David S. Miller's avatar
      Merge branch 'hns3-fixes' · 251ffc07
      David S. Miller authored
      Guangbin Huang says:
      
      ====================
      net: hns3: add some fixes for -net
      
      This series adds some fixes for the HNS3 ethernet driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      251ffc07
    • Guangbin Huang's avatar
      net: hns3: disable firmware compatible features when uninstall PF · 0178839c
      Guangbin Huang authored
      Currently, the firmware compatible features are enabled in PF driver
      initialization process, but they are not disabled in PF driver
      deinitialization process and firmware keeps these features in enabled
      status.
      
      In this case, if load an old PF driver (for example, in VM) which not
      support the firmware compatible features, firmware will still send mailbox
      message to PF when link status changed and PF will print
      "un-supported mailbox message, code = 201".
      
      To fix this problem, disable these firmware compatible features in PF
      driver deinitialization process.
      
      Fixes: ed8fb4b2 ("net: hns3: add link change event report")
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0178839c
    • Guangbin Huang's avatar
      net: hns3: fix always enable rx vlan filter problem after selftest · 27bf4af6
      Guangbin Huang authored
      Currently, the rx vlan filter will always be disabled before selftest and
      be enabled after selftest as the rx vlan filter feature is fixed on in
      old device earlier than V3.
      
      However, this feature is not fixed in some new devices and it can be
      disabled by user. In this case, it is wrong if rx vlan filter is enabled
      after selftest. So fix it.
      
      Fixes: bcc26e8d ("net: hns3: remove unused code in hns3_self_test()")
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27bf4af6
    • Guangbin Huang's avatar
      net: hns3: PF enable promisc for VF when mac table is overflow · 276e6042
      Guangbin Huang authored
      If unicast mac address table is full, and user add a new mac address, the
      unicast promisc needs to be enabled for the new unicast mac address can be
      used. So does the multicast promisc.
      
      Now this feature has been implemented for PF, and VF should be implemented
      too. When the mac table of VF is overflow, PF will enable promisc for this
      VF.
      
      Fixes: 1e6e7610 ("net: hns3: configure promisc mode for VF asynchronously")
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      276e6042
    • Jian Shen's avatar
      net: hns3: fix show wrong state when add existing uc mac address · 108b3c78
      Jian Shen authored
      Currently, if function adds an existing unicast mac address, eventhough
      driver will not add this address into hardware, but it will return 0 in
      function hclge_add_uc_addr_common(). It will cause the state of this
      unicast mac address is ACTIVE in driver, but it should be in TO-ADD state.
      
      To fix this problem, function hclge_add_uc_addr_common() returns -EEXIST
      if mac address is existing, and delete two error log to avoid printing
      them all the time after this modification.
      
      Fixes: 72110b56 ("net: hns3: return 0 and print warning when hit duplicate MAC")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      108b3c78
    • Jian Shen's avatar
      net: hns3: fix mixed flag HCLGE_FLAG_MQPRIO_ENABLE and HCLGE_FLAG_DCB_ENABLE · 0472e95f
      Jian Shen authored
      HCLGE_FLAG_MQPRIO_ENABLE is supposed to set when enable
      multiple TCs with tc mqprio, and HCLGE_FLAG_DCB_ENABLE is
      supposed to set when enable multiple TCs with ets. But
      the driver mixed the flags when updating the tm configuration.
      
      Furtherly, PFC should be available when HCLGE_FLAG_MQPRIO_ENABLE
      too, so remove the unnecessary limitation.
      
      Fixes: 5a5c9091 ("net: hns3: add support for tc mqprio offload")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0472e95f
    • Jian Shen's avatar
      net: hns3: don't rollback when destroy mqprio fail · d82650be
      Jian Shen authored
      For destroy mqprio is irreversible in stack, so it's unnecessary
      to rollback the tc configuration when destroy mqprio failed.
      Otherwise, it may cause the configuration being inconsistent
      between driver and netstack.
      
      As the failure is usually caused by reset, and the driver will
      restore the configuration after reset, so it can keep the
      configuration being consistent between driver and hardware.
      
      Fixes: 5a5c9091 ("net: hns3: add support for tc mqprio offload")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d82650be
    • Jian Shen's avatar
      net: hns3: remove tc enable checking · a8e76fef
      Jian Shen authored
      Currently, in function hns3_nic_set_real_num_queue(), the
      driver doesn't report the queue count and offset for disabled
      tc. If user enables multiple TCs, but only maps user
      priorities to partial of them, it may cause the queue range
      of the unmapped TC being displayed abnormally.
      
      Fix it by removing the tc enable checking, ensure the queue
      count is not zero.
      
      With this change, the tc_en is useless now, so remove it.
      
      Fixes: a75a8efa ("net: hns3: Fix tc setup when netdev is first up")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8e76fef
    • Jian Shen's avatar
      net: hns3: do not allow call hns3_nic_net_open repeatedly · 5b09e88e
      Jian Shen authored
      hns3_nic_net_open() is not allowed to called repeatly, but there
      is no checking for this. When doing device reset and setup tc
      concurrently, there is a small oppotunity to call hns3_nic_net_open
      repeatedly, and cause kernel bug by calling napi_enable twice.
      
      The calltrace information is like below:
      [ 3078.222780] ------------[ cut here ]------------
      [ 3078.230255] kernel BUG at net/core/dev.c:6991!
      [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O)
      [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G           O      5.14.0-rc4+ #1
      [ 3078.269102] Hardware name:  , BIOS KpxxxFPGA 1P B600 V181 08/12/2021
      [ 3078.276801] Workqueue: hclge hclge_service_task [hclge]
      [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
      [ 3078.296168] pc : napi_enable+0x80/0x84
      tc qdisc sho[w  3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3]
      
      [ 3078.314771] sp : ffff8000108abb20
      [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300
      [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000
      [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880
      [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000
      [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930
      [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4
      [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8
      [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344
      [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938
      [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0
      [ 3078.414657] Call trace:
      [ 3078.418517]  napi_enable+0x80/0x84
      [ 3078.424626]  hns3_reset_notify_up_enet+0x78/0xd0 [hns3]
      [ 3078.433469]  hns3_reset_notify+0x64/0x80 [hns3]
      [ 3078.441430]  hclge_notify_client+0x68/0xb0 [hclge]
      [ 3078.450511]  hclge_reset_rebuild+0x524/0x884 [hclge]
      [ 3078.458879]  hclge_reset_service_task+0x3c4/0x680 [hclge]
      [ 3078.467470]  hclge_service_task+0xb0/0xb54 [hclge]
      [ 3078.475675]  process_one_work+0x1dc/0x48c
      [ 3078.481888]  worker_thread+0x15c/0x464
      [ 3078.487104]  kthread+0x160/0x170
      [ 3078.492479]  ret_from_fork+0x10/0x18
      [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000)
      [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---
      
      Once hns3_nic_net_open() is excute success, the flag
      HNS3_NIC_STATE_DOWN will be cleared. So add checking for this
      flag, directly return when HNS3_NIC_STATE_DOWN is no set.
      
      Fixes: e8884027 ("net: hns3: call hns3_nic_net_open() while doing HNAE3_UP_CLIENT")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b09e88e
    • Feng Zhou's avatar
      ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup · 513e605d
      Feng Zhou authored
      The ixgbe driver currently generates a NULL pointer dereference with
      some machine (online cpus < 63). This is due to the fact that the
      maximum value of num_xdp_queues is nr_cpu_ids. Code is in
      "ixgbe_set_rss_queues"".
      
      Here's how the problem repeats itself:
      Some machine (online cpus < 63), And user set num_queues to 63 through
      ethtool. Code is in the "ixgbe_set_channels",
      	adapter->ring_feature[RING_F_FDIR].limit = count;
      
      It becomes 63.
      
      When user use xdp, "ixgbe_set_rss_queues" will set queues num.
      	adapter->num_rx_queues = rss_i;
      	adapter->num_tx_queues = rss_i;
      	adapter->num_xdp_queues = ixgbe_xdp_queues(adapter);
      
      And rss_i's value is from
      	f = &adapter->ring_feature[RING_F_FDIR];
      	rss_i = f->indices = f->limit;
      
      So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup",
      	for (i = 0; i < adapter->num_rx_queues; i++)
      		if (adapter->xdp_ring[i]->xsk_umem)
      
      It leads to panic.
      
      Call trace:
      [exception RIP: ixgbe_xdp+368]
      RIP: ffffffffc02a76a0  RSP: ffff9fe16202f8d0  RFLAGS: 00010297
      RAX: 0000000000000000  RBX: 0000000000000020  RCX: 0000000000000000
      RDX: 0000000000000000  RSI: 000000000000001c  RDI: ffffffffa94ead90
      RBP: ffff92f8f24c0c18   R8: 0000000000000000   R9: 0000000000000000
      R10: ffff9fe16202f830  R11: 0000000000000000  R12: ffff92f8f24c0000
      R13: ffff9fe16202fc01  R14: 000000000000000a  R15: ffffffffc02a7530
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc
       8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808
       9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235
      10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384
      11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd
      12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb
      13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88
      14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319
      15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290
      16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8
      17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64
      18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9
      19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c
      
      So I fix ixgbe_max_channels so that it will not allow a setting of queues
      to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,
      take the smaller value of num_rx_queues and num_xdp_queues.
      
      Fixes: 4a9b32f3 ("ixgbe: fix potential RX buffer starvation for AF_XDP")
      Signed-off-by: default avatarFeng Zhou <zhoufeng.zf@bytedance.com>
      Tested-by: default avatarSandeep Penigalapati <sandeep.penigalapati@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      513e605d
    • Thomas Gleixner's avatar
      net: bridge: mcast: Associate the seqcount with its protecting lock. · f936bb42
      Thomas Gleixner authored
      The sequence count bridge_mcast_querier::seq is protected by
      net_bridge::multicast_lock but seqcount_init() does not associate the
      seqcount with the lock. This leads to a warning on PREEMPT_RT because
      preemption is still enabled.
      
      Let seqcount_init() associate the seqcount with lock that protects the
      write section. Remove lockdep_assert_held_once() because lockdep already checks
      whether the associated lock is held.
      
      Fixes: 67b746f9 ("net: bridge: mcast: make sure querier port/address updates are consistent")
      Reported-by: default avatarMike Galbraith <efault@gmx.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Tested-by: default avatarMike Galbraith <efault@gmx.de>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Link: https://lore.kernel.org/r/20210928141049.593833-1-bigeasy@linutronix.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f936bb42
    • Cai Huoqing's avatar
      net: mdio-ipq4019: Fix the error for an optional regs resource · 9e28cfea
      Cai Huoqing authored
      The second resource is optional which is only provided on the chipset
      IPQ5018. But the blamed commit ignores that and if the resource is
      not there it just fails.
      
      the resource is used like this,
      	if (priv->eth_ldo_rdy) {
      		val = readl(priv->eth_ldo_rdy);
      		val |= BIT(0);
      		writel(val, priv->eth_ldo_rdy);
      		fsleep(IPQ_PHY_SET_DELAY_US);
      	}
      
      This patch reverts that to still allow the second resource to be optional
      because other SoC have the some MDIO controller and doesn't need to
      second resource.
      
      Fixes: fa14d03e ("net: mdio-ipq4019: Make use of devm_platform_ioremap_resource()")
      Signed-off-by: default avatarCai Huoqing <caihuoqing@baidu.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20210928134849.2092-1-caihuoqing@baidu.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9e28cfea
  3. 28 Sep, 2021 18 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 4ccb9f03
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2021-09-28
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 10 non-merge commits during the last 14 day(s) which contain
      a total of 11 files changed, 139 insertions(+), 53 deletions(-).
      
      The main changes are:
      
      1) Fix MIPS JIT jump code emission for too large offsets, from Piotr Krysiuk.
      
      2) Fix x86 JIT atomic/fetch emission when dst reg maps to rax, from Johan Almbladh.
      
      3) Fix cgroup_sk_alloc corner case when called from interrupt, from Daniel Borkmann.
      
      4) Fix segfault in libbpf's linker for objects without BTF, from Kumar Kartikeya Dwivedi.
      
      5) Fix bpf_jit_charge_modmem for applications with CAP_BPF, from Lorenz Bauer.
      
      6) Fix return value handling for struct_ops BPF programs, from Hou Tao.
      
      7) Various fixes to BPF selftests, from Jiri Benc.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ,
      4ccb9f03
    • Arnd Bergmann's avatar
      net: hns3: fix hclge_dbg_dump_tm_pg() stack usage · c894b51e
      Arnd Bergmann authored
      This function copies strings around between multiple buffers
      including a large on-stack array that causes a build warning
      on 32-bit systems:
      
      drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c: In function 'hclge_dbg_dump_tm_pg':
      drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c:782:1: error: the frame size of 1424 bytes is larger than 1400 bytes [-Werror=frame-larger-than=]
      
      The function can probably be cleaned up a lot, to go back to
      printing directly into the output buffer, but dynamically allocating
      the structure is a simpler workaround for now.
      
      Fixes: 04d96139 ("net: hns3: refine function hclge_dbg_dump_tm_pri()")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c894b51e
    • Horatiu Vultur's avatar
      net: mdio: mscc-miim: Fix the mdio controller · c6995117
      Horatiu Vultur authored
      According to the documentation the second resource is optional. But the
      blamed commit ignores that and if the resource is not there it just
      fails.
      
      This patch reverts that to still allow the second resource to be
      optional because other SoC have the some MDIO controller and doesn't
      need to second resource.
      
      Fixes: 672a1c39 ("net: mdio: mscc-miim: Make use of the helper function devm_platform_ioremap_resource()")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Reviewed-by: default avatarCai Huoqing <caihuoqing@baidu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6995117
    • Kuniyuki Iwashima's avatar
      af_unix: Return errno instead of NULL in unix_create1(). · f4bd73b5
      Kuniyuki Iwashima authored
      unix_create1() returns NULL on error, and the callers assume that it never
      fails for reasons other than out of memory.  So, the callers always return
      -ENOMEM when unix_create1() fails.
      
      However, it also returns NULL when the number of af_unix sockets exceeds
      twice the limit controlled by sysctl: fs.file-max.  In this case, the
      callers should return -ENFILE like alloc_empty_file().
      
      This patch changes unix_create1() to return the correct error value instead
      of NULL on error.
      
      Out of curiosity, the assumption has been wrong since 1999 due to this
      change introduced in 2.2.4 [0].
      
        diff -u --recursive --new-file v2.2.3/linux/net/unix/af_unix.c linux/net/unix/af_unix.c
        --- v2.2.3/linux/net/unix/af_unix.c	Tue Jan 19 11:32:53 1999
        +++ linux/net/unix/af_unix.c	Sun Mar 21 07:22:00 1999
        @@ -388,6 +413,9 @@
         {
         	struct sock *sk;
      
        +	if (atomic_read(&unix_nr_socks) >= 2*max_files)
        +		return NULL;
        +
         	MOD_INC_USE_COUNT;
         	sk = sk_alloc(PF_UNIX, GFP_KERNEL, 1);
         	if (!sk) {
      
      [0]: https://cdn.kernel.org/pub/linux/kernel/v2.2/patch-2.2.4.gz
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f4bd73b5
    • Eric Dumazet's avatar
      net: udp: annotate data race around udp_sk(sk)->corkflag · a9f59707
      Eric Dumazet authored
      up->corkflag field can be read or written without any lock.
      Annotate accesses to avoid possible syzbot/KCSAN reports.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a9f59707
    • Randy Dunlap's avatar
      net: sun: SUNVNET_COMMON should depend on INET · 103bde37
      Randy Dunlap authored
      When CONFIG_INET is not set, there are failing references to IPv4
      functions, so make this driver depend on INET.
      
      Fixes these build errors:
      
      sparc64-linux-ld: drivers/net/ethernet/sun/sunvnet_common.o: in function `sunvnet_start_xmit_common':
      sunvnet_common.c:(.text+0x1a68): undefined reference to `__icmp_send'
      sparc64-linux-ld: drivers/net/ethernet/sun/sunvnet_common.o: in function `sunvnet_poll_common':
      sunvnet_common.c:(.text+0x358c): undefined reference to `ip_send_check'
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Aaron Young <aaron.young@oracle.com>
      Cc: Rashmi Narasimhan <rashmi.narasimhan@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      103bde37
    • Shannon Nelson's avatar
      ionic: fix gathering of debug stats · c23bb54f
      Shannon Nelson authored
      Don't print stats for which we haven't reserved space as it can
      cause nasty memory bashing and related bad behaviors.
      
      Fixes: aa620993 ("ionic: pull per-q stats work out of queue loops")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c23bb54f
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/t · 3fb2a54b
      David S. Miller authored
      nguy/net-queue
      
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2021-09-27
      
      This series contains updates to e100 driver only.
      
      Jake corrects under allocation of register buffer due to incorrect
      calculations and fixes buffer overrun of register dump.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3fb2a54b
    • Arnd Bergmann's avatar
      dmascc: add CONFIG_VIRT_TO_BUS dependency · 05e97b3d
      Arnd Bergmann authored
      Many architectures don't define virt_to_bus() any more, as drivers
      should be using the dma-mapping interfaces where possible:
      
      In file included from drivers/net/hamradio/dmascc.c:27:
      drivers/net/hamradio/dmascc.c: In function 'tx_on':
      drivers/net/hamradio/dmascc.c:976:30: error: implicit declaration of function 'virt_to_bus'; did you mean 'virt_to_fix'? [-Werror=implicit-function-declaration]
        976 |                              virt_to_bus(priv->tx_buf[priv->tx_tail]) + n);
            |                              ^~~~~~~~~~~
      arch/arm/include/asm/dma.h:109:52: note: in definition of macro 'set_dma_addr'
        109 |         __set_dma_addr(chan, (void *)__bus_to_virt(addr))
            |                                                    ^~~~
      
      Add the Kconfig dependency to prevent this from being built on
      architectures without virt_to_bus().
      
      Fixes: bc1abb9e ("dmascc: use proper 'virt_to_bus()' rather than casting to 'int'")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05e97b3d
    • Arnd Bergmann's avatar
      net: ks8851: fix link error · 51bb08dd
      Arnd Bergmann authored
      An object file cannot be built for both loadable module and built-in
      use at the same time:
      
      arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function `ks8851_probe_common':
      ks8851_common.c:(.text+0xf80): undefined reference to `__this_module'
      
      Change the ks8851_common code to be a standalone module instead,
      and use Makefile logic to ensure this is built-in if at least one
      of its two users is.
      
      Fixes: 797047f8 ("net: ks8851: Implement Parallel bus operations")
      Link: https://lore.kernel.org/netdev/20210125121937.3900988-1-arnd@kernel.org/Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51bb08dd
    • Johan Almbladh's avatar
      bpf, x86: Fix bpf mapping of atomic fetch implementation · ced18582
      Johan Almbladh authored
      Fix the case where the dst register maps to %rax as otherwise this produces
      an incorrect mapping with the implementation in 981f94c3 ("bpf: Add
      bitwise atomic instructions") as %rax is clobbered given it's part of the
      cmpxchg as operand.
      
      The issue is similar to b29dd96b ("bpf, x86: Fix BPF_FETCH atomic and/or/
      xor with r0 as src") just that the case of dst register was missed.
      
      Before, dst=r0 (%rax) src=r2 (%rsi):
      
        [...]
        c5:   mov    %rax,%r10
        c8:   mov    0x0(%rax),%rax       <---+ (broken)
        cc:   mov    %rax,%r11                |
        cf:   and    %rsi,%r11                |
        d2:   lock cmpxchg %r11,0x0(%rax) <---+
        d8:   jne    0x00000000000000c8       |
        da:   mov    %rax,%rsi                |
        dd:   mov    %r10,%rax                |
        [...]                                 |
                                              |
      After, dst=r0 (%rax) src=r2 (%rsi):     |
                                              |
        [...]                                 |
        da:	mov    %rax,%r10                |
        dd:	mov    0x0(%r10),%rax       <---+ (fixed)
        e1:	mov    %rax,%r11                |
        e4:	and    %rsi,%r11                |
        e7:	lock cmpxchg %r11,0x0(%r10) <---+
        ed:	jne    0x00000000000000dd
        ef:	mov    %rax,%rsi
        f2:	mov    %r10,%rax
        [...]
      
      The remaining combinations were fine as-is though:
      
      After, dst=r9 (%r15) src=r0 (%rax):
      
        [...]
        dc:	mov    %rax,%r10
        df:	mov    0x0(%r15),%rax
        e3:	mov    %rax,%r11
        e6:	and    %r10,%r11
        e9:	lock cmpxchg %r11,0x0(%r15)
        ef:	jne    0x00000000000000df      _
        f1:	mov    %rax,%r10                | (unneeded, but
        f4:	mov    %r10,%rax               _|  not a problem)
        [...]
      
      After, dst=r9 (%r15) src=r4 (%rcx):
      
        [...]
        de:	mov    %rax,%r10
        e1:	mov    0x0(%r15),%rax
        e5:	mov    %rax,%r11
        e8:	and    %rcx,%r11
        eb:	lock cmpxchg %r11,0x0(%r15)
        f1:	jne    0x00000000000000e1
        f3:	mov    %rax,%rcx
        f6:	mov    %r10,%rax
        [...]
      
      The case of dst == src register is rejected by the verifier and
      therefore not supported, but x86 JIT also handles this case just
      fine.
      
      After, dst=r0 (%rax) src=r0 (%rax):
      
        [...]
        eb:	mov    %rax,%r10
        ee:	mov    0x0(%r10),%rax
        f2:	mov    %rax,%r11
        f5:	and    %r10,%r11
        f8:	lock cmpxchg %r11,0x0(%r10)
        fe:	jne    0x00000000000000ee
       100:	mov    %rax,%r10
       103:	mov    %r10,%rax
        [...]
      
      Fixes: 981f94c3 ("bpf: Add bitwise atomic instructions")
      Reported-by: default avatarJohan Almbladh <johan.almbladh@anyfinetworks.com>
      Signed-off-by: default avatarJohan Almbladh <johan.almbladh@anyfinetworks.com>
      Co-developed-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarBrendan Jackman <jackmanb@google.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      ced18582
    • Jiri Benc's avatar
      selftests, bpf: test_lwt_ip_encap: Really disable rp_filter · 79e2c306
      Jiri Benc authored
      It's not enough to set net.ipv4.conf.all.rp_filter=0, that does not override
      a greater rp_filter value on the individual interfaces. We also need to set
      net.ipv4.conf.default.rp_filter=0 before creating the interfaces. That way,
      they'll also get their own rp_filter value of zero.
      
      Fixes: 0fde56e4 ("selftests: bpf: add test_lwt_ip_encap selftest")
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/b1cdd9d469f09ea6e01e9c89a6071c79b7380f89.1632386362.git.jbenc@redhat.com
      79e2c306
    • Jiri Benc's avatar
      selftests, bpf: Fix makefile dependencies on libbpf · d888eaac
      Jiri Benc authored
      When building bpf selftest with make -j, I'm randomly getting build failures
      such as this one:
      
        In file included from progs/bpf_flow.c:19:
        [...]/tools/testing/selftests/bpf/tools/include/bpf/bpf_helpers.h:11:10: fatal error: 'bpf_helper_defs.h' file not found
        #include "bpf_helper_defs.h"
                 ^~~~~~~~~~~~~~~~~~~
      
      The file that fails the build varies between runs but it's always in the
      progs/ subdir.
      
      The reason is a missing make dependency on libbpf for the .o files in
      progs/. There was a dependency before commit 3ac2e20f but that commit
      removed it to prevent unneeded rebuilds. However, that only works if libbpf
      has been built already; the 'wildcard' prerequisite does not trigger when
      there's no bpf_helper_defs.h generated yet.
      
      Keep the libbpf as an order-only prerequisite to satisfy both goals. It is
      always built before the progs/ objects but it does not trigger unnecessary
      rebuilds by itself.
      
      Fixes: 3ac2e20f ("selftests/bpf: BPF object files should depend only on libbpf headers")
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/ee84ab66436fba05a197f952af23c98d90eb6243.1632758415.git.jbenc@redhat.com
      d888eaac
    • Daniel Borkmann's avatar
      bpf, test, cgroup: Use sk_{alloc,free} for test cases · 435b08ec
      Daniel Borkmann authored
      BPF test infra has some hacks in place which kzalloc() a socket and perform
      minimum init via sock_net_set() and sock_init_data(). As a result, the sk's
      skcd->cgroup is NULL since it didn't go through proper initialization as it
      would have been the case from sk_alloc(). Rather than re-adding a NULL test
      in sock_cgroup_ptr() just for this, use sk_{alloc,free}() pair for the test
      socket. The latter also allows to get rid of the bpf_sk_storage_free() special
      case.
      
      Fixes: 8520e224 ("bpf, cgroups: Fix cgroup v2 fallback on v1/v2 mixed mode")
      Fixes: b7a1848e ("bpf: add BPF_PROG_TEST_RUN support for flow dissector")
      Fixes: 2cb494a3 ("bpf: add tests for direct packet access from CGROUP_SKB")
      Reported-by: syzbot+664b58e9a40fbb2cec71@syzkaller.appspotmail.com
      Reported-by: syzbot+33f36d0754d4c5c0e102@syzkaller.appspotmail.com
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Tested-by: syzbot+664b58e9a40fbb2cec71@syzkaller.appspotmail.com
      Tested-by: syzbot+33f36d0754d4c5c0e102@syzkaller.appspotmail.com
      Link: https://lore.kernel.org/bpf/20210927123921.21535-2-daniel@iogearbox.net
      435b08ec
    • Daniel Borkmann's avatar
      bpf, cgroup: Assign cgroup in cgroup_sk_alloc when called from interrupt · 78cc316e
      Daniel Borkmann authored
      If cgroup_sk_alloc() is called from interrupt context, then just assign the
      root cgroup to skcd->cgroup. Prior to commit 8520e224 ("bpf, cgroups:
      Fix cgroup v2 fallback on v1/v2 mixed mode") we would just return, and later
      on in sock_cgroup_ptr(), we were NULL-testing the cgroup in fast-path, and
      iff indeed NULL returning the root cgroup (v ?: &cgrp_dfl_root.cgrp). Rather
      than re-adding the NULL-test to the fast-path we can just assign it once from
      cgroup_sk_alloc() given v1/v2 handling has been simplified. The migration from
      NULL test with returning &cgrp_dfl_root.cgrp to assigning &cgrp_dfl_root.cgrp
      directly does /not/ change behavior for callers of sock_cgroup_ptr().
      
      syzkaller was able to trigger a splat in the legacy netrom code base, where
      the RX handler in nr_rx_frame() calls nr_make_new() which calls sk_alloc()
      and therefore cgroup_sk_alloc() with in_interrupt() condition. Thus the NULL
      skcd->cgroup, where it trips over on cgroup_sk_free() side given it expects
      a non-NULL object. There are a few other candidates aside from netrom which
      have similar pattern where in their accept-like implementation, they just call
      to sk_alloc() and thus cgroup_sk_alloc() instead of sk_clone_lock() with the
      corresponding cgroup_sk_clone() which then inherits the cgroup from the parent
      socket. None of them are related to core protocols where BPF cgroup programs
      are running from. However, in future, they should follow to implement a similar
      inheritance mechanism.
      
      Additionally, with a !CONFIG_CGROUP_NET_PRIO and !CONFIG_CGROUP_NET_CLASSID
      configuration, the same issue was exposed also prior to 8520e224 due to
      commit e876ecc6 ("cgroup: memcg: net: do not associate sock with unrelated
      cgroup") which added the early in_interrupt() return back then.
      
      Fixes: 8520e224 ("bpf, cgroups: Fix cgroup v2 fallback on v1/v2 mixed mode")
      Fixes: e876ecc6 ("cgroup: memcg: net: do not associate sock with unrelated cgroup")
      Reported-by: syzbot+df709157a4ecaf192b03@syzkaller.appspotmail.com
      Reported-by: syzbot+533f389d4026d86a2a95@syzkaller.appspotmail.com
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Tested-by: syzbot+df709157a4ecaf192b03@syzkaller.appspotmail.com
      Tested-by: syzbot+533f389d4026d86a2a95@syzkaller.appspotmail.com
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Link: https://lore.kernel.org/bpf/20210927123921.21535-1-daniel@iogearbox.net
      78cc316e
    • Kumar Kartikeya Dwivedi's avatar
      libbpf: Fix segfault in static linker for objects without BTF · bcfd367c
      Kumar Kartikeya Dwivedi authored
      When a BPF object is compiled without BTF info (without -g),
      trying to link such objects using bpftool causes a SIGSEGV due to
      btf__get_nr_types accessing obj->btf which is NULL. Fix this by
      checking for the NULL pointer, and return error.
      
      Reproducer:
      $ cat a.bpf.c
      extern int foo(void);
      int bar(void) { return foo(); }
      $ cat b.bpf.c
      int foo(void) { return 0; }
      $ clang -O2 -target bpf -c a.bpf.c
      $ clang -O2 -target bpf -c b.bpf.c
      $ bpftool gen obj out a.bpf.o b.bpf.o
      Segmentation fault (core dumped)
      
      After fix:
      $ bpftool gen obj out a.bpf.o b.bpf.o
      libbpf: failed to find BTF info for object 'a.bpf.o'
      Error: failed to link 'a.bpf.o': Unknown error -22 (-22)
      
      Fixes: a4634922 (libbpf: Add linker extern resolution support for functions and global variables)
      Signed-off-by: default avatarKumar Kartikeya Dwivedi <memxor@gmail.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20210924023725.70228-1-memxor@gmail.com
      bcfd367c
    • Dave Marchevsky's avatar
      MAINTAINERS: Add btf headers to BPF · b3aa173d
      Dave Marchevsky authored
      BPF folks maintain these and they're not picked up by the current
      MAINTAINERS entries.
      
      Files caught by the added globs:
      
        include/linux/btf.h
        include/linux/btf_ids.h
        include/uapi/linux/btf.h
      Signed-off-by: default avatarDave Marchevsky <davemarchevsky@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20210924193557.3081469-1-davemarchevsky@fb.com
      b3aa173d
    • Lorenz Bauer's avatar
      bpf: Exempt CAP_BPF from checks against bpf_jit_limit · 8a98ae12
      Lorenz Bauer authored
      When introducing CAP_BPF, bpf_jit_charge_modmem() was not changed to treat
      programs with CAP_BPF as privileged for the purpose of JIT memory allocation.
      This means that a program without CAP_BPF can block a program with CAP_BPF
      from loading a program.
      
      Fix this by checking bpf_capable() in bpf_jit_charge_modmem().
      
      Fixes: 2c78ee89 ("bpf: Implement CAP_BPF")
      Signed-off-by: default avatarLorenz Bauer <lmb@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20210922111153.19843-1-lmb@cloudflare.com
      8a98ae12
  4. 27 Sep, 2021 8 commits
    • Jacob Keller's avatar
      e100: fix buffer overrun in e100_get_regs · 51032e6f
      Jacob Keller authored
      The e100_get_regs function is used to implement a simple register dump
      for the e100 device. The data is broken into a couple of MAC control
      registers, and then a series of PHY registers, followed by a memory dump
      buffer.
      
      The total length of the register dump is defined as (1 + E100_PHY_REGS)
      * sizeof(u32) + sizeof(nic->mem->dump_buf).
      
      The logic for filling in the PHY registers uses a convoluted inverted
      count for loop which counts from E100_PHY_REGS (0x1C) down to 0, and
      assigns the slots 1 + E100_PHY_REGS - i. The first loop iteration will
      fill in [1] and the final loop iteration will fill in [1 + 0x1C]. This
      is actually one more than the supposed number of PHY registers.
      
      The memory dump buffer is then filled into the space at
      [2 + E100_PHY_REGS] which will cause that memcpy to assign 4 bytes past
      the total size.
      
      The end result is that we overrun the total buffer size allocated by the
      kernel, which could lead to a panic or other issues due to memory
      corruption.
      
      It is difficult to determine the actual total number of registers
      here. The only 8255x datasheet I could find indicates there are 28 total
      MDI registers. However, we're reading 29 here, and reading them in
      reverse!
      
      In addition, the ethtool e100 register dump interface appears to read
      the first PHY register to determine if the device is in MDI or MDIx
      mode. This doesn't appear to be documented anywhere within the 8255x
      datasheet. I can only assume it must be in register 28 (the extra
      register we're reading here).
      
      Lets not change any of the intended meaning of what we copy here. Just
      extend the space by 4 bytes to account for the extra register and
      continue copying the data out in the same order.
      
      Change the E100_PHY_REGS value to be the correct total (29) so that the
      total register dump size is calculated properly. Fix the offset for
      where we copy the dump buffer so that it doesn't overrun the total size.
      
      Re-write the for loop to use counting up instead of the convoluted
      down-counting. Correct the mdio_read offset to use the 0-based register
      offsets, but maintain the bizarre reverse ordering so that we have the
      ABI expected by applications like ethtool. This requires and additional
      subtraction of 1. It seems a bit odd but it makes the flow of assignment
      into the register buffer easier to follow.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarFelicitas Hetzelt <felicitashetzelt@gmail.com>
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      51032e6f
    • Jacob Keller's avatar
      e100: fix length calculation in e100_get_regs_len · 4329c8dc
      Jacob Keller authored
      commit abf9b902 ("e100: cleanup unneeded math") tried to simplify
      e100_get_regs_len and remove a double 'divide and then multiply'
      calculation that the e100_reg_regs_len function did.
      
      This change broke the size calculation entirely as it failed to account
      for the fact that the numbered registers are actually 4 bytes wide and
      not 1 byte. This resulted in a significant under allocation of the
      register buffer used by e100_get_regs.
      
      Fix this by properly multiplying the register count by u32 first before
      adding the size of the dump buffer.
      
      Fixes: abf9b902 ("e100: cleanup unneeded math")
      Reported-by: default avatarFelicitas Hetzelt <felicitashetzelt@gmail.com>
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      4329c8dc
    • Xu Liang's avatar
      net: phy: enhance GPY115 loopback disable function · 3b1b6e82
      Xu Liang authored
      GPY115 need reset PHY when it comes out from loopback mode if the firmware
      version number (lower 8 bits) is equal to or below 0x76.
      
      Fixes: 7d901a1e ("net: phy: add Maxlinear GPY115/21x/24x driver")
      Signed-off-by: default avatarXu Liang <lxu@maxlinear.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b1b6e82
    • David S. Miller's avatar
      Merge tag 'mac80211-for-net-2021-09-27' of... · ca48aa4a
      David S. Miller authored
      Merge tag 'mac80211-for-net-2021-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes berg says:
      
      ====================
      Some fixes:
       * potential use-after-free in CCMP/GCMP RX processing
       * potential use-after-free in TX A-MSDU processing
       * revert to low data rates for no-ack as the commit
         broke other things
       * limit VHT MCS/NSS in radiotap injection
       * drop frames with invalid addresses in IBSS mode
       * check rhashtable_init() return value in mesh
       * fix potentially unaligned access in mesh
       * fix late beacon hrtimer handling in hwsim (syzbot)
       * fix documentation for PTK0 rekeying
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca48aa4a
    • David S. Miller's avatar
      Merge branch 'mv88e6xxx-mtu-fixes' · 3ebaaad4
      David S. Miller authored
      Andrew Lunn says:
      
      ====================
      mv88e6xxx: MTU fixes
      
      These three patches fix MTU issues reported by 曹煜.
      
      There are two different ways of configuring the MTU in the hardware.
      The 6161 family is using the wrong method. Some of the marvell switch
      enforce the MTU when the port is used for CPU/DSA, some don't.
      Because of the extra header, the MTU needs increasing with this
      overhead.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ebaaad4
    • Andrew Lunn's avatar
      dsa: mv88e6xxx: Include tagger overhead when setting MTU for DSA and CPU ports · b9c587fe
      Andrew Lunn authored
      Same members of the Marvell Ethernet switches impose MTU restrictions
      on ports used for connecting to the CPU or another switch for DSA. If
      the MTU is set too low, tagged frames will be discarded. Ensure the
      worst case tagger overhead is included in setting the MTU for DSA and
      CPU ports.
      
      Fixes: 1baf0fac ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU")
      Reported by: 曹煜 <cao88yu@gmail.com>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9c587fe
    • Andrew Lunn's avatar
      dsa: mv88e6xxx: Fix MTU definition · b92ce2f5
      Andrew Lunn authored
      The MTU passed to the DSA driver is the payload size, typically 1500.
      However, the switch uses the frame size when applying restrictions.
      Adjust the MTU with the size of the Ethernet header and the frame
      checksum. The VLAN header also needs to be included when the frame
      size it per port, but not when it is global.
      
      Fixes: 1baf0fac ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU")
      Reported by: 曹煜 <cao88yu@gmail.com>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b92ce2f5
    • Andrew Lunn's avatar
      dsa: mv88e6xxx: 6161: Use chip wide MAX MTU · fe230361
      Andrew Lunn authored
      The datasheets suggests the 6161 uses a per port setting for jumbo
      frames. Testing has however shown this is not correct, it uses the old
      style chip wide MTU control. Change the ops in the 6161 structure to
      reflect this.
      
      Fixes: 1baf0fac ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU")
      Reported by: 曹煜 <cao88yu@gmail.com>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe230361