1. 05 Jun, 2023 10 commits
    • Geliang Tang's avatar
      mptcp: add address into userspace pm list · 24430f8b
      Geliang Tang authored
      Add the address into userspace_pm_local_addr_list when the subflow is
      created. Make sure it can be found in mptcp_nl_cmd_remove(). And delete
      it in the new helper mptcp_userspace_pm_delete_local_addr().
      
      By doing this, the "REMOVE" command also works with subflows that have
      been created via the "SUB_CREATE" command instead of restricting to
      the addresses that have been announced via the "ANNOUNCE" command.
      
      Fixes: d9a4594e ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/379
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarGeliang Tang <geliang.tang@suse.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24430f8b
    • Geliang Tang's avatar
      selftests: mptcp: update userspace pm addr tests · 48d73f60
      Geliang Tang authored
      This patch is linked to the previous commit ("mptcp: only send RM_ADDR in
      nl_cmd_remove").
      
      To align with what is done by the in-kernel PM, update userspace pm addr
      selftests, by sending a remove_subflows command together after the
      remove_addrs command.
      
      Fixes: d9a4594e ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
      Fixes: 97040cf9 ("selftests: mptcp: userspace pm address tests")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarGeliang Tang <geliang.tang@suse.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48d73f60
    • Geliang Tang's avatar
      mptcp: only send RM_ADDR in nl_cmd_remove · 8b1c94da
      Geliang Tang authored
      The specifications from [1] about the "REMOVE" command say:
      
          Announce that an address has been lost to the peer
      
      It was then only supposed to send a RM_ADDR and not trying to delete
      associated subflows.
      
      A new helper mptcp_pm_remove_addrs() is then introduced to do just
      that, compared to mptcp_pm_remove_addrs_and_subflows() also removing
      subflows.
      
      To delete a subflow, the userspace daemon can use the "SUB_DESTROY"
      command, see mptcp_nl_cmd_sf_destroy().
      
      Fixes: d9a4594e ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
      Link: https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.96/include/uapi/linux/mptcp.h [1]
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarGeliang Tang <geliang.tang@suse.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b1c94da
    • Bartosz Golaszewski's avatar
      net: stmmac: dwmac-qcom-ethqos: fix a regression on EMAC < 3 · 9bc00973
      Bartosz Golaszewski authored
      We must not assign plat_dat->dwmac4_addrs unconditionally as for
      structures which don't set them, this will result in the core driver
      using zeroes everywhere and breaking the driver for older HW. On EMAC < 2
      the address should remain NULL.
      
      Fixes: b6837619 ("net: stmmac: dwmac-qcom-ethqos: Add EMAC3 support")
      Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
      Reviewed-by: default avatarAndrew Halaney <ahalaney@redhat.com>
      Reviewed-by: default avatarSiddharth Vadapalli <s-vadapalli@ti.com>
      Reviewed-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9bc00973
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-6.4-20230605' of... · d7536931
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-6.4-20230605' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      
      this is a pull request of 3 patches for net/master.
      
      All 3 patches target the j1939 stack.
      
      The 1st patch is by Oleksij Rempel and fixes the error queue handling
      for (E)TP sessions that run into timeouts.
      
      The last 2 patches are by Fedor Pchelkin and fix a potential
      use-after-free in j1939_netdev_start() if j1939_can_rx_register()
      fails.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7536931
    • Eric Dumazet's avatar
      net/sched: fq_pie: ensure reasonable TCA_FQ_PIE_QUANTUM values · cd2b8113
      Eric Dumazet authored
      We got multiple syzbot reports, all duplicates of the following [1]
      
      syzbot managed to install fq_pie with a zero TCA_FQ_PIE_QUANTUM,
      thus triggering infinite loops.
      
      Use limits similar to sch_fq, with commits
      3725a269 ("pkt_sched: fq: avoid hang when quantum 0") and
      d9e15a27 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
      
      [1]
      watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:0]
      Modules linked in:
      irq event stamp: 172817
      hardirqs last enabled at (172816): [<ffff80001242fde4>] __el1_irq arch/arm64/kernel/entry-common.c:476 [inline]
      hardirqs last enabled at (172816): [<ffff80001242fde4>] el1_interrupt+0x58/0x68 arch/arm64/kernel/entry-common.c:486
      hardirqs last disabled at (172817): [<ffff80001242fdb0>] __el1_irq arch/arm64/kernel/entry-common.c:468 [inline]
      hardirqs last disabled at (172817): [<ffff80001242fdb0>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:486
      softirqs last enabled at (167634): [<ffff800008020c1c>] softirq_handle_end kernel/softirq.c:414 [inline]
      softirqs last enabled at (167634): [<ffff800008020c1c>] __do_softirq+0xac0/0xd54 kernel/softirq.c:600
      softirqs last disabled at (167701): [<ffff80000802a660>] ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:80
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-rc3-syzkaller-geb0f1697d729 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023
      pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : fq_pie_qdisc_dequeue+0x10c/0x8ac net/sched/sch_fq_pie.c:246
      lr : fq_pie_qdisc_dequeue+0xe4/0x8ac net/sched/sch_fq_pie.c:240
      sp : ffff800008007210
      x29: ffff800008007280 x28: ffff0000c86f7890 x27: ffff0000cb20c2e8
      x26: ffff0000cb20c2f0 x25: dfff800000000000 x24: ffff0000cb20c2e0
      x23: ffff0000c86f7880 x22: 0000000000000040 x21: 1fffe000190def10
      x20: ffff0000cb20c2e0 x19: ffff0000cb20c2e0 x18: ffff800008006e60
      x17: 0000000000000000 x16: ffff80000850af6c x15: 0000000000000302
      x14: 0000000000000100 x13: 0000000000000000 x12: 0000000000000001
      x11: 0000000000000302 x10: 0000000000000100 x9 : 0000000000000000
      x8 : 0000000000000000 x7 : ffff80000841c468 x6 : 0000000000000000
      x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000
      x2 : ffff0000cb20c2e0 x1 : ffff0000cb20c2e0 x0 : 0000000000000001
      Call trace:
      fq_pie_qdisc_dequeue+0x10c/0x8ac net/sched/sch_fq_pie.c:246
      dequeue_skb net/sched/sch_generic.c:292 [inline]
      qdisc_restart net/sched/sch_generic.c:397 [inline]
      __qdisc_run+0x1fc/0x231c net/sched/sch_generic.c:415
      __dev_xmit_skb net/core/dev.c:3868 [inline]
      __dev_queue_xmit+0xc80/0x3318 net/core/dev.c:4210
      dev_queue_xmit include/linux/netdevice.h:3085 [inline]
      neigh_connected_output+0x2f8/0x38c net/core/neighbour.c:1581
      neigh_output include/net/neighbour.h:544 [inline]
      ip6_finish_output2+0xd60/0x1a1c net/ipv6/ip6_output.c:134
      __ip6_finish_output net/ipv6/ip6_output.c:195 [inline]
      ip6_finish_output+0x538/0x8c8 net/ipv6/ip6_output.c:206
      NF_HOOK_COND include/linux/netfilter.h:292 [inline]
      ip6_output+0x270/0x594 net/ipv6/ip6_output.c:227
      dst_output include/net/dst.h:458 [inline]
      NF_HOOK include/linux/netfilter.h:303 [inline]
      ndisc_send_skb+0xc30/0x1790 net/ipv6/ndisc.c:508
      ndisc_send_rs+0x47c/0x5d4 net/ipv6/ndisc.c:718
      addrconf_rs_timer+0x300/0x58c net/ipv6/addrconf.c:3936
      call_timer_fn+0x19c/0x8cc kernel/time/timer.c:1700
      expire_timers kernel/time/timer.c:1751 [inline]
      __run_timers+0x55c/0x734 kernel/time/timer.c:2022
      run_timer_softirq+0x7c/0x114 kernel/time/timer.c:2035
      __do_softirq+0x2d0/0xd54 kernel/softirq.c:571
      ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:80
      call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:882
      do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:85
      invoke_softirq kernel/softirq.c:452 [inline]
      __irq_exit_rcu+0x28c/0x534 kernel/softirq.c:650
      irq_exit_rcu+0x14/0x84 kernel/softirq.c:662
      __el1_irq arch/arm64/kernel/entry-common.c:472 [inline]
      el1_interrupt+0x38/0x68 arch/arm64/kernel/entry-common.c:486
      el1h_64_irq_handler+0x18/0x24 arch/arm64/kernel/entry-common.c:491
      el1h_64_irq+0x64/0x68 arch/arm64/kernel/entry.S:587
      __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:33 [inline]
      arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:55
      cpuidle_idle_call kernel/sched/idle.c:170 [inline]
      do_idle+0x1f0/0x4e8 kernel/sched/idle.c:282
      cpu_startup_entry+0x24/0x28 kernel/sched/idle.c:379
      rest_init+0x2dc/0x2f4 init/main.c:735
      start_kernel+0x0/0x55c init/main.c:834
      start_kernel+0x3f0/0x55c init/main.c:1088
      __primary_switched+0xb8/0xc0 arch/arm64/kernel/head.S:523
      
      Fixes: ec97ecf1 ("net: sched: add Flow Queue PIE packet scheduler")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd2b8113
    • Marc Kleine-Budde's avatar
      Merge patch series "can: j1939: avoid possible use-after-free when j1939_can_rx_register fails" · 628f725d
      Marc Kleine-Budde authored
      Fedor Pchelkin <pchelkin@ispras.ru> says:
      
      The patch series fixes a possible racy use-after-free scenario
      described in 2/2: if j1939_can_rx_register() fails then the concurrent
      thread may have already read the invalid priv structure.
      
      The 1/2 makes j1939_netdev_lock a mutex so that access to
      j1939_can_rx_register() can be serialized without changing GFP_KERNEL
      to GFP_ATOMIC inside can_rx_register(). This seems to be safe.
      
      Note that the patch series has been tested only via Syzkaller and not
      with a real device.
      
      Link: https://lore.kernel.org/r/20230526171910.227615-1-pchelkin@ispras.ruSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      628f725d
    • Fedor Pchelkin's avatar
      can: j1939: avoid possible use-after-free when j1939_can_rx_register fails · 9f16eb10
      Fedor Pchelkin authored
      Syzkaller reports the following failure:
      
      BUG: KASAN: use-after-free in kref_put include/linux/kref.h:64 [inline]
      BUG: KASAN: use-after-free in j1939_priv_put+0x25/0xa0 net/can/j1939/main.c:172
      Write of size 4 at addr ffff888141c15058 by task swapper/3/0
      
      CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.10.144-syzkaller #0
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x107/0x167 lib/dump_stack.c:118
       print_address_description.constprop.0+0x1c/0x220 mm/kasan/report.c:385
       __kasan_report mm/kasan/report.c:545 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
       check_memory_region_inline mm/kasan/generic.c:186 [inline]
       check_memory_region+0x145/0x190 mm/kasan/generic.c:192
       instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
       atomic_fetch_sub_release include/asm-generic/atomic-instrumented.h:220 [inline]
       __refcount_sub_and_test include/linux/refcount.h:272 [inline]
       __refcount_dec_and_test include/linux/refcount.h:315 [inline]
       refcount_dec_and_test include/linux/refcount.h:333 [inline]
       kref_put include/linux/kref.h:64 [inline]
       j1939_priv_put+0x25/0xa0 net/can/j1939/main.c:172
       j1939_sk_sock_destruct+0x44/0x90 net/can/j1939/socket.c:374
       __sk_destruct+0x4e/0x820 net/core/sock.c:1784
       rcu_do_batch kernel/rcu/tree.c:2485 [inline]
       rcu_core+0xb35/0x1a30 kernel/rcu/tree.c:2726
       __do_softirq+0x289/0x9a3 kernel/softirq.c:298
       asm_call_irq_on_stack+0x12/0x20
       </IRQ>
       __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
       run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
       do_softirq_own_stack+0xaa/0xe0 arch/x86/kernel/irq_64.c:77
       invoke_softirq kernel/softirq.c:393 [inline]
       __irq_exit_rcu kernel/softirq.c:423 [inline]
       irq_exit_rcu+0x136/0x200 kernel/softirq.c:435
       sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1095
       asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:635
      
      Allocated by task 1141:
       kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
       kasan_set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc.constprop.0+0xc9/0xd0 mm/kasan/common.c:461
       kmalloc include/linux/slab.h:552 [inline]
       kzalloc include/linux/slab.h:664 [inline]
       j1939_priv_create net/can/j1939/main.c:131 [inline]
       j1939_netdev_start+0x111/0x860 net/can/j1939/main.c:268
       j1939_sk_bind+0x8ea/0xd30 net/can/j1939/socket.c:485
       __sys_bind+0x1f2/0x260 net/socket.c:1645
       __do_sys_bind net/socket.c:1656 [inline]
       __se_sys_bind net/socket.c:1654 [inline]
       __x64_sys_bind+0x6f/0xb0 net/socket.c:1654
       do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x61/0xc6
      
      Freed by task 1141:
       kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
       kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
       kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
       __kasan_slab_free+0x112/0x170 mm/kasan/common.c:422
       slab_free_hook mm/slub.c:1542 [inline]
       slab_free_freelist_hook+0xad/0x190 mm/slub.c:1576
       slab_free mm/slub.c:3149 [inline]
       kfree+0xd9/0x3b0 mm/slub.c:4125
       j1939_netdev_start+0x5ee/0x860 net/can/j1939/main.c:300
       j1939_sk_bind+0x8ea/0xd30 net/can/j1939/socket.c:485
       __sys_bind+0x1f2/0x260 net/socket.c:1645
       __do_sys_bind net/socket.c:1656 [inline]
       __se_sys_bind net/socket.c:1654 [inline]
       __x64_sys_bind+0x6f/0xb0 net/socket.c:1654
       do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x61/0xc6
      
      It can be caused by this scenario:
      
      CPU0					CPU1
      j1939_sk_bind(socket0, ndev0, ...)
        j1939_netdev_start()
      					j1939_sk_bind(socket1, ndev0, ...)
                                                j1939_netdev_start()
        mutex_lock(&j1939_netdev_lock)
        j1939_priv_set(ndev0, priv)
        mutex_unlock(&j1939_netdev_lock)
      					  if (priv_new)
      					    kref_get(&priv_new->rx_kref)
      					    return priv_new;
      					  /* inside j1939_sk_bind() */
      					  jsk->priv = priv
        j1939_can_rx_register(priv) // fails
        j1939_priv_set(ndev, NULL)
        kfree(priv)
      					j1939_sk_sock_destruct()
      					j1939_priv_put() // <- uaf
      
      To avoid this, call j1939_can_rx_register() under j1939_netdev_lock so
      that a concurrent thread cannot process j1939_priv before
      j1939_can_rx_register() returns.
      
      Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
      
      Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol")
      Signed-off-by: default avatarFedor Pchelkin <pchelkin@ispras.ru>
      Tested-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Acked-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Link: https://lore.kernel.org/r/20230526171910.227615-3-pchelkin@ispras.ru
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      9f16eb10
    • Fedor Pchelkin's avatar
      can: j1939: change j1939_netdev_lock type to mutex · cd9c790d
      Fedor Pchelkin authored
      It turns out access to j1939_can_rx_register() needs to be serialized,
      otherwise j1939_priv can be corrupted when parallel threads call
      j1939_netdev_start() and j1939_can_rx_register() fails. This issue is
      thoroughly covered in other commit which serializes access to
      j1939_can_rx_register().
      
      Change j1939_netdev_lock type to mutex so that we do not need to remove
      GFP_KERNEL from can_rx_register().
      
      j1939_netdev_lock seems to be used in normal contexts where mutex usage
      is not prohibited.
      
      Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
      
      Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol")
      Suggested-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarFedor Pchelkin <pchelkin@ispras.ru>
      Tested-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Acked-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Link: https://lore.kernel.org/r/20230526171910.227615-2-pchelkin@ispras.ru
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      cd9c790d
    • Oleksij Rempel's avatar
      can: j1939: j1939_sk_send_loop_abort(): improved error queue handling in J1939 Socket · 2a84aea8
      Oleksij Rempel authored
      This patch addresses an issue within the j1939_sk_send_loop_abort()
      function in the j1939/socket.c file, specifically in the context of
      Transport Protocol (TP) sessions.
      
      Without this patch, when a TP session is initiated and a Clear To Send
      (CTS) frame is received from the remote side requesting one data packet,
      the kernel dispatches the first Data Transport (DT) frame and then waits
      for the next CTS. If the remote side doesn't respond with another CTS,
      the kernel aborts due to a timeout. This leads to the user-space
      receiving an EPOLLERR on the socket, and the socket becomes active.
      
      However, when trying to read the error queue from the socket with
      sock.recvmsg(, , socket.MSG_ERRQUEUE), it returns -EAGAIN,
      given that the socket is non-blocking. This situation results in an
      infinite loop: the user-space repeatedly calls epoll(), epoll() returns
      the socket file descriptor with EPOLLERR, but the socket then blocks on
      the recv() of ERRQUEUE.
      
      This patch introduces an additional check for the J1939_SOCK_ERRQUEUE
      flag within the j1939_sk_send_loop_abort() function. If the flag is set,
      it indicates that the application has subscribed to receive error queue
      messages. In such cases, the kernel can communicate the current transfer
      state via the error queue. This allows for the function to return early,
      preventing the unnecessary setting of the socket into an error state,
      and breaking the infinite loop. It is crucial to note that a socket
      error is only needed if the application isn't using the error queue, as,
      without it, the application wouldn't be aware of transfer issues.
      
      Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol")
      Reported-by: default avatarDavid Jander <david@protonic.nl>
      Tested-by: default avatarDavid Jander <david@protonic.nl>
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Link: https://lore.kernel.org/r/20230526081946.715190-1-o.rempel@pengutronix.de
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      2a84aea8
  2. 04 Jun, 2023 4 commits
  3. 03 Jun, 2023 6 commits
  4. 02 Jun, 2023 5 commits
  5. 01 Jun, 2023 15 commits
    • Linus Torvalds's avatar
      Merge tag 'net-6.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 714069da
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Happy Wear a Dress Day.
      
        Fairly standard-sized batch of fixes, accounting for the lack of
        sub-tree submissions this week. The mlx5 IRQ fixes are notable, people
        were complaining about that. No fires burning.
      
        Current release - regressions:
      
         - eth: mlx5e:
            - multiple fixes for dynamic IRQ allocation
            - prevent encap offload when neigh update is running
      
         - eth: mana: fix perf regression: remove rx_cqes, tx_cqes counters
      
        Current release - new code bugs:
      
         - eth: mlx5e: DR, add missing mutex init/destroy in pattern manager
      
        Previous releases - always broken:
      
         - tcp: deny tcp_disconnect() when threads are waiting
      
         - sched: prevent ingress Qdiscs from getting installed in random
           locations in the hierarchy and moving around
      
         - sched: flower: fix possible OOB write in fl_set_geneve_opt()
      
         - netlink: fix NETLINK_LIST_MEMBERSHIPS length report
      
         - udp6: fix race condition in udp6_sendmsg & connect
      
         - tcp: fix mishandling when the sack compression is deferred
      
         - rtnetlink: validate link attributes set at creation time
      
         - mptcp: fix connect timeout handling
      
         - eth: stmmac: fix call trace when stmmac_xdp_xmit() is invoked
      
         - eth: amd-xgbe: fix the false linkup in xgbe_phy_status
      
         - eth: mlx5e:
            - fix corner cases in internal buffer configuration
            - drain health before unregistering devlink
      
         - usb: qmi_wwan: set DTR quirk for BroadMobi BM818
      
        Misc:
      
         - tcp: return user_mss for TCP_MAXSEG in CLOSE/LISTEN state if
           user_mss set"
      
      * tag 'net-6.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (71 commits)
        mptcp: fix active subflow finalization
        mptcp: add annotations around sk->sk_shutdown accesses
        mptcp: fix data race around msk->first access
        mptcp: consolidate passive msk socket initialization
        mptcp: add annotations around msk->subflow accesses
        mptcp: fix connect timeout handling
        rtnetlink: add the missing IFLA_GRO_ tb check in validate_linkmsg
        rtnetlink: move IFLA_GSO_ tb check to validate_linkmsg
        rtnetlink: call validate_linkmsg in rtnl_create_link
        ice: recycle/free all of the fragments from multi-buffer frame
        net: phy: mxl-gpy: extend interrupt fix to all impacted variants
        net: renesas: rswitch: Fix return value in error path of xmit
        net: dsa: mv88e6xxx: Increase wait after reset deactivation
        net: ipa: Use correct value for IPA_STATUS_SIZE
        tcp: fix mishandling when the sack compression is deferred.
        net/sched: flower: fix possible OOB write in fl_set_geneve_opt()
        sfc: fix error unwinds in TC offload
        net/mlx5: Read embedded cpu after init bit cleared
        net/mlx5e: Fix error handling in mlx5e_refresh_tirs
        net/mlx5: Ensure af_desc.mask is properly initialized
        ...
      714069da
    • Mike Christie's avatar
      fork, vhost: Use CLONE_THREAD to fix freezer/ps regression · f9010dbd
      Mike Christie authored
      When switching from kthreads to vhost_tasks two bugs were added:
      1. The vhost worker tasks's now show up as processes so scripts doing
      ps or ps a would not incorrectly detect the vhost task as another
      process.  2. kthreads disabled freeze by setting PF_NOFREEZE, but
      vhost tasks's didn't disable or add support for them.
      
      To fix both bugs, this switches the vhost task to be thread in the
      process that does the VHOST_SET_OWNER ioctl, and has vhost_worker call
      get_signal to support SIGKILL/SIGSTOP and freeze signals. Note that
      SIGKILL/STOP support is required because CLONE_THREAD requires
      CLONE_SIGHAND which requires those 2 signals to be supported.
      
      This is a modified version of the patch written by Mike Christie
      <michael.christie@oracle.com> which was a modified version of patch
      originally written by Linus.
      
      Much of what depended upon PF_IO_WORKER now depends on PF_USER_WORKER.
      Including ignoring signals, setting up the register state, and having
      get_signal return instead of calling do_group_exit.
      
      Tidied up the vhost_task abstraction so that the definition of
      vhost_task only needs to be visible inside of vhost_task.c.  Making
      it easier to review the code and tell what needs to be done where.
      As part of this the main loop has been moved from vhost_worker into
      vhost_task_fn.  vhost_worker now returns true if work was done.
      
      The main loop has been updated to call get_signal which handles
      SIGSTOP, freezing, and collects the message that tells the thread to
      exit as part of process exit.  This collection clears
      __fatal_signal_pending.  This collection is not guaranteed to
      clear signal_pending() so clear that explicitly so the schedule()
      sleeps.
      
      For now the vhost thread continues to exist and run work until the
      last file descriptor is closed and the release function is called as
      part of freeing struct file.  To avoid hangs in the coredump
      rendezvous and when killing threads in a multi-threaded exec.  The
      coredump code and de_thread have been modified to ignore vhost threads.
      
      Remvoing the special case for exec appears to require teaching
      vhost_dev_flush how to directly complete transactions in case
      the vhost thread is no longer running.
      
      Removing the special case for coredump rendezvous requires either the
      above fix needed for exec or moving the coredump rendezvous into
      get_signal.
      
      Fixes: 6e890c5d ("vhost: use vhost_tasks for worker threads")
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Co-developed-by: default avatarMike Christie <michael.christie@oracle.com>
      Signed-off-by: default avatarMike Christie <michael.christie@oracle.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f9010dbd
    • Jakub Kicinski's avatar
      Merge tag 'mlx5-fixes-2023-05-31' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · a451b8eb
      Jakub Kicinski authored
      Saeed Mahameed says:
      
      ====================
      mlx5 fixes 2023-05-31
      
      This series provides bug fixes to mlx5 driver.
      
      * tag 'mlx5-fixes-2023-05-31' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
        net/mlx5: Read embedded cpu after init bit cleared
        net/mlx5e: Fix error handling in mlx5e_refresh_tirs
        net/mlx5: Ensure af_desc.mask is properly initialized
        net/mlx5: Fix setting of irq->map.index for static IRQ case
        net/mlx5: Remove rmap also in case dynamic MSIX not supported
      ====================
      
      Link: https://lore.kernel.org/r/20230601031051.131529-1-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a451b8eb
    • Jakub Kicinski's avatar
      Merge branch 'mptcp-fixes-for-connect-timeout-access-annotations-and-subflow-init' · 66dd1014
      Jakub Kicinski authored
      Mat Martineau says:
      
      ====================
      mptcp: Fixes for connect timeout, access annotations, and subflow init
      
      Patch 1 allows the SO_SNDTIMEO sockopt to correctly change the connect
      timeout on MPTCP sockets.
      
      Patches 2-5 add READ_ONCE()/WRITE_ONCE() annotations to fix KCSAN issues.
      
      Patch 6 correctly initializes some subflow fields on outgoing connections.
      ====================
      
      Link: https://lore.kernel.org/r/20230531-send-net-20230531-v1-0-47750c420571@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      66dd1014
    • Paolo Abeni's avatar
      mptcp: fix active subflow finalization · 55b47ca7
      Paolo Abeni authored
      Active subflow are inserted into the connection list at creation time.
      When the MPJ handshake completes successfully, a new subflow creation
      netlink event is generated correctly, but the current code wrongly
      avoid initializing a couple of subflow data.
      
      The above will cause misbehavior on a few exceptional events: unneeded
      mptcp-level retransmission on msk-level sequence wrap-around and infinite
      mapping fallback even when a MPJ socket is present.
      
      Address the issue factoring out the needed initialization in a new helper
      and invoking the latter from __mptcp_finish_join() time for passive
      subflow and from mptcp_finish_join() for active ones.
      
      Fixes: 0530020a ("mptcp: track and update contiguous data status")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      55b47ca7
    • Paolo Abeni's avatar
      mptcp: add annotations around sk->sk_shutdown accesses · 6b9831bf
      Paolo Abeni authored
      Christoph reported the mptcp variant of a recently addressed plain
      TCP issue. Similar to commit e14cadfd ("tcp: add annotations around
      sk->sk_shutdown accesses") add READ/WRITE ONCE annotations to silence
      KCSAN reports around lockless sk_shutdown access.
      
      Fixes: 71ba088c ("mptcp: cleanup accept and poll")
      Reported-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/401Reviewed-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6b9831bf
    • Paolo Abeni's avatar
      mptcp: fix data race around msk->first access · 1b1b43ee
      Paolo Abeni authored
      The first subflow socket is accessed outside the msk socket lock
      by mptcp_subflow_fail(), we need to annotate each write access
      with WRITE_ONCE, but a few spots still lacks it.
      
      Fixes: 76a13b31 ("mptcp: invoke MP_FAIL response when needed")
      Reviewed-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1b1b43ee
    • Paolo Abeni's avatar
      mptcp: consolidate passive msk socket initialization · 7e8b88ec
      Paolo Abeni authored
      When the msk socket is cloned at MPC handshake time, a few
      fields are initialized in a racy way outside mptcp_sk_clone()
      and the msk socket lock.
      
      The above is due historical reasons: before commit a88d0092
      ("mptcp: simplify subflow_syn_recv_sock()") as the first subflow socket
      carrying all the needed date was not available yet at msk creation
      time
      
      We can now refactor the code moving the missing initialization bit
      under the socket lock, removing the init race and avoiding some
      code duplication.
      
      This will also simplify the next patch, as all msk->first write
      access are now under the msk socket lock.
      
      Fixes: 0397c6d8 ("mptcp: keep unaccepted MPC subflow into join list")
      Reviewed-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7e8b88ec
    • Paolo Abeni's avatar
      mptcp: add annotations around msk->subflow accesses · 5b825727
      Paolo Abeni authored
      The MPTCP can access the first subflow socket in a few spots
      outside the socket lock scope. That is actually safe, as MPTCP
      will delete the socket itself only after the msk sock close().
      
      Still the such accesses causes a few KCSAN splats, as reported
      by Christoph. Silence the harmless warning adding a few annotation
      around the relevant accesses.
      
      Fixes: 71ba088c ("mptcp: cleanup accept and poll")
      Reported-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/402Reviewed-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5b825727
    • Paolo Abeni's avatar
      mptcp: fix connect timeout handling · 786fc124
      Paolo Abeni authored
      Ondrej reported a functional issue WRT timeout handling on connect
      with a nice reproducer.
      
      The problem is that the current mptcp connect waits for both the
      MPTCP socket level timeout, and the first subflow socket timeout.
      The latter is not influenced/touched by the exposed setsockopt().
      
      Overall the above makes the SO_SNDTIMEO a no-op on connect.
      
      Since mptcp_connect is invoked via inet_stream_connect and the
      latter properly handle the MPTCP level timeout, we can address the
      issue making the nested subflow level connect always unblocking.
      
      This also allow simplifying a bit the code, dropping an ugly hack
      to handle the fastopen and custom proto_ops connect.
      
      The issues predates the blamed commit below, but the current resolution
      requires the infrastructure introduced there.
      
      Fixes: 54f1944e ("mptcp: factor out mptcp_connect()")
      Reported-by: default avatarOndrej Mosnacek <omosnace@redhat.com>
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/399
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <martineau@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      786fc124
    • Jakub Kicinski's avatar
      Merge branch 'rtnetlink-a-couple-of-fixes-in-linkmsg-validation' · 3021dbfe
      Jakub Kicinski authored
      Xin Long says:
      
      ====================
      rtnetlink: a couple of fixes in linkmsg validation
      
      validate_linkmsg() was introduced to do linkmsg validation for existing
      links. However, the new created links also need this linkmsg validation.
      
      Add validate_linkmsg() check for link creating in Patch 1, and add more
      tb checks into validate_linkmsg() in Patch 2 and 3.
      ====================
      
      Link: https://lore.kernel.org/r/cover.1685548598.git.lucien.xin@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3021dbfe
    • Xin Long's avatar
      rtnetlink: add the missing IFLA_GRO_ tb check in validate_linkmsg · 65d6914e
      Xin Long authored
      This fixes the issue that dev gro_max_size and gso_ipv4_max_size
      can be set to a huge value:
      
        # ip link add dummy1 type dummy
        # ip link set dummy1 gro_max_size 4294967295
        # ip -d link show dummy1
          dummy addrgenmode eui64 ... gro_max_size 4294967295
      
      Fixes: 0fe79f28 ("net: allow gro_max_size to exceed 65536")
      Fixes: 9eefedd5 ("net: add gso_ipv4_max_size and gro_ipv4_max_size per device")
      Reported-by: default avatarXiumei Mu <xmu@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      65d6914e
    • Xin Long's avatar
      rtnetlink: move IFLA_GSO_ tb check to validate_linkmsg · fef5b228
      Xin Long authored
      These IFLA_GSO_* tb check should also be done for the new created link,
      otherwise, they can be set to a huge value when creating links:
      
        # ip link add dummy1 gso_max_size 4294967295 type dummy
        # ip -d link show dummy1
          dummy addrgenmode eui64 ... gso_max_size 4294967295
      
      Fixes: 46e6b992 ("rtnetlink: allow GSO maximums to be set on device creation")
      Fixes: 9eefedd5 ("net: add gso_ipv4_max_size and gro_ipv4_max_size per device")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fef5b228
    • Xin Long's avatar
      rtnetlink: call validate_linkmsg in rtnl_create_link · b0ad3c17
      Xin Long authored
      validate_linkmsg() was introduced by commit 1840bb13 ("[RTNL]:
      Validate hardware and broadcast address attribute for RTM_NEWLINK")
      to validate tb[IFLA_ADDRESS/BROADCAST] for existing links. The same
      check should also be done for newly created links.
      
      This patch adds validate_linkmsg() call in rtnl_create_link(), to
      avoid the invalid address set when creating some devices like:
      
        # ip link add dummy0 type dummy
        # ip link add link dummy0 name mac0 address 01:02 type macsec
      
      Fixes: 0e06877c ("[RTNETLINK]: rtnl_link: allow specifying initial device address")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b0ad3c17
    • Maciej Fijalkowski's avatar
      ice: recycle/free all of the fragments from multi-buffer frame · abaf8d51
      Maciej Fijalkowski authored
      The ice driver caches next_to_clean value at the beginning of
      ice_clean_rx_irq() in order to remember the first buffer that has to be
      freed/recycled after main Rx processing loop. The end boundary is
      indicated by first descriptor of frame that Rx processing loop has ended
      its duties. Note that if mentioned loop ended in the middle of gathering
      multi-buffer frame, next_to_clean would be pointing to the descriptor in
      the middle of the frame BUT freeing/recycling stage will stop at the
      first descriptor. This means that next iteration of ice_clean_rx_irq()
      will miss the (first_desc, next_to_clean - 1) entries.
      
       When running various 9K MTU workloads, such splats were observed:
      
      [  540.780716] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [  540.787787] #PF: supervisor read access in kernel mode
      [  540.793002] #PF: error_code(0x0000) - not-present page
      [  540.798218] PGD 0 P4D 0
      [  540.800801] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [  540.805231] CPU: 18 PID: 3984 Comm: xskxceiver Tainted: G        W          6.3.0-rc7+ #96
      [  540.813619] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
      [  540.824209] RIP: 0010:ice_clean_rx_irq+0x2b6/0xf00 [ice]
      [  540.829678] Code: 74 24 10 e9 aa 00 00 00 8b 55 78 41 31 57 10 41 09 c4 4d 85 ff 0f 84 83 00 00 00 49 8b 57 08 41 8b 4f 1c 65 8b 35 1a fa 4b 3f <48> 8b 02 48 c1 e8 3a 39 c6 0f 85 a2 00 00 00 f6 42 08 02 0f 85 98
      [  540.848717] RSP: 0018:ffffc9000f42fc50 EFLAGS: 00010282
      [  540.854029] RAX: 0000000000000004 RBX: 0000000000000002 RCX: 000000000000fffe
      [  540.861272] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00000000ffffffff
      [  540.868519] RBP: ffff88984a05ac00 R08: 0000000000000000 R09: dead000000000100
      [  540.875760] R10: ffff88983fffcd00 R11: 000000000010f2b8 R12: 0000000000000004
      [  540.883008] R13: 0000000000000003 R14: 0000000000000800 R15: ffff889847a10040
      [  540.890253] FS:  00007f6ddf7fe640(0000) GS:ffff88afdf800000(0000) knlGS:0000000000000000
      [  540.898465] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  540.904299] CR2: 0000000000000000 CR3: 000000010d3da001 CR4: 00000000007706e0
      [  540.911542] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  540.918789] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  540.926032] PKRU: 55555554
      [  540.928790] Call Trace:
      [  540.931276]  <TASK>
      [  540.933418]  ice_napi_poll+0x4ca/0x6d0 [ice]
      [  540.937804]  ? __pfx_ice_napi_poll+0x10/0x10 [ice]
      [  540.942716]  napi_busy_loop+0xd7/0x320
      [  540.946537]  xsk_recvmsg+0x143/0x170
      [  540.950178]  sock_recvmsg+0x99/0xa0
      [  540.953729]  __sys_recvfrom+0xa8/0x120
      [  540.957543]  ? do_futex+0xbd/0x1d0
      [  540.961008]  ? __x64_sys_futex+0x73/0x1d0
      [  540.965083]  __x64_sys_recvfrom+0x20/0x30
      [  540.969155]  do_syscall_64+0x38/0x90
      [  540.972796]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
      [  540.977934] RIP: 0033:0x7f6de5f27934
      
      To fix this, set cached_ntc to first_desc so that at the end, when
      freeing/recycling buffers, descriptors from first to ntc are not missed.
      
      Fixes: 2fba7dc5 ("ice: Add support for XDP multi-buffer on Rx side")
      Signed-off-by: default avatarMaciej Fijalkowski <maciej.fijalkowski@intel.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Link: https://lore.kernel.org/r/20230531154457.3216621-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      abaf8d51