1. 27 3月, 2021 4 次提交
  2. 13 3月, 2021 6 次提交
  3. 09 3月, 2021 1 次提交
    • D
      mptcp: fix length of ADD_ADDR with port sub-option · 27ab92d9
      Davide Caratti 提交于
      in current Linux, MPTCP peers advertising endpoints with port numbers use
      a sub-option length that wrongly accounts for the trailing TCP NOP. Also,
      receivers will only process incoming ADD_ADDR with port having such wrong
      sub-option length. Fix this, making ADD_ADDR compliant to RFC8684 §3.4.1.
      
      this can be verified running tcpdump on the kselftests artifacts:
      
       unpatched kernel:
       [root@bottarga mptcp]# tcpdump -tnnr unpatched.pcap | grep add-addr
       reading from file unpatched.pcap, link-type LINUX_SLL (Linux cooked v1), snapshot length 65535
       IP 10.0.1.1.10000 > 10.0.1.2.53078: Flags [.], ack 101, win 509, options [nop,nop,TS val 214459678 ecr 521312851,mptcp add-addr v1 id 1 a00:201:2774:2d88:7436:85c3:17fd:101], length 0
       IP 10.0.1.2.53078 > 10.0.1.1.10000: Flags [.], ack 101, win 502, options [nop,nop,TS val 521312852 ecr 214459678,mptcp add-addr[bad opt]]
      
       patched kernel:
       [root@bottarga mptcp]# tcpdump -tnnr patched.pcap | grep add-addr
       reading from file patched.pcap, link-type LINUX_SLL (Linux cooked v1), snapshot length 65535
       IP 10.0.1.1.10000 > 10.0.1.2.38178: Flags [.], ack 101, win 509, options [nop,nop,TS val 3728873902 ecr 2732713192,mptcp add-addr v1 id 1 10.0.2.1:10100 hmac 0xbccdfcbe59292a1f,nop,nop], length 0
       IP 10.0.1.2.38178 > 10.0.1.1.10000: Flags [.], ack 101, win 502, options [nop,nop,TS val 2732713195 ecr 3728873902,mptcp add-addr v1-echo id 1 10.0.2.1:10100,nop,nop], length 0
      
      Fixes: 22fb85ff ("mptcp: add port support for ADD_ADDR suboption writing")
      CC: stable@vger.kernel.org # 5.11+
      Reviewed-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Acked-and-tested-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27ab92d9
  4. 16 2月, 2021 1 次提交
  5. 13 2月, 2021 4 次提交
  6. 12 2月, 2021 3 次提交
    • P
      mptcp: better msk receive window updates · e3859603
      Paolo Abeni 提交于
      Move mptcp_cleanup_rbuf() related checks inside the mentioned
      helper and extend them to mirror TCP checks more closely.
      
      Additionally drop the 'rmem_pending' hack, since commit 87952603
      ("mptcp: protect the rx path with the msk socket spinlock") we
      can use instead 'rmem_released'.
      
      Fixes: ea4ca586 ("mptcp: refine MPTCP-level ack scheduling")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3859603
    • P
      mptcp: fix spurious retransmissions · 64b9cea7
      Paolo Abeni 提交于
      Syzkaller was able to trigger the following splat again:
      
      WARNING: CPU: 1 PID: 12512 at net/mptcp/protocol.c:761 mptcp_reset_timer+0x12a/0x160 net/mptcp/protocol.c:761
      Modules linked in:
      CPU: 1 PID: 12512 Comm: kworker/1:6 Not tainted 5.10.0-rc6 #52
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      Workqueue: events mptcp_worker
      RIP: 0010:mptcp_reset_timer+0x12a/0x160 net/mptcp/protocol.c:761
      Code: e8 4b 0c ad ff e8 56 21 88 fe 48 b8 00 00 00 00 00 fc ff df 48 c7 04 03 00 00 00 00 48 83 c4 40 5b 5d 41 5c c3 e8 36 21 88 fe <0f> 0b 41 bc c8 00 00 00 eb 98 e8 e7 b1 af fe e9 30 ff ff ff 48 c7
      RSP: 0018:ffffc900018c7c68 EFLAGS: 00010293
      RAX: ffff888108cb1c80 RBX: 1ffff92000318f8d RCX: ffffffff82ad0307
      RDX: 0000000000000000 RSI: ffffffff82ad036a RDI: 0000000000000007
      RBP: ffff888113e2d000 R08: ffff888108cb1c80 R09: ffffed10227c5ab7
      R10: ffff888113e2d5b7 R11: ffffed10227c5ab6 R12: 0000000000000000
      R13: ffff88801f100000 R14: ffff888113e2d5b0 R15: 0000000000000001
      FS:  0000000000000000(0000) GS:ffff88811b500000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fd76a874ef8 CR3: 000000001689c005 CR4: 0000000000170ee0
      Call Trace:
       mptcp_worker+0xaa4/0x1560 net/mptcp/protocol.c:2334
       process_one_work+0x8d3/0x1200 kernel/workqueue.c:2272
       worker_thread+0x9c/0x1090 kernel/workqueue.c:2418
       kthread+0x303/0x410 kernel/kthread.c:292
       ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:296
      
      The mptcp_worker tries to update the MPTCP retransmission timer
      even if such timer is not currently scheduled.
      
      The mptcp_rtx_head() return value is bogus: we can have enqueued
      data not yet transmitted. The above may additionally cause spurious,
      unneeded MPTCP-level retransmissions.
      
      Fix the issue adding an explicit clearing of the rtx queue before
      trying to retransmit and checking for unacked data.
      Additionally drop an unneeded timer stop call and the unused
      mptcp_rtx_tail() helper.
      Reported-by: NChristoph Paasch <cpaasch@apple.com>
      Fixes: 6e628cd3 ("mptcp: use mptcp release_cb for delayed tasks")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64b9cea7
    • P
      mptcp: deliver ssk errors to msk · 15cc1045
      Paolo Abeni 提交于
      Currently all errors received on msk subflows are ignored.
      We need to catch at least the errors on connect() and
      on fallback sockets.
      
      Use a custom sk_error_report callback at subflow level,
      and do the real action under the msk socket lock - via
      the usual sock_owned_by_user()/release_callback() schema.
      
      Fixes: 6e628cd3 ("mptcp: use mptcp release_cb for delayed tasks")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15cc1045
  7. 07 2月, 2021 1 次提交
  8. 03 2月, 2021 4 次提交
  9. 23 1月, 2021 3 次提交
    • P
      mptcp: implement delegated actions · b19bc294
      Paolo Abeni 提交于
      On MPTCP-level ack reception, the packet scheduler
      may select a subflow other then the current one.
      
      Prior to this commit we rely on the workqueue to trigger
      action on such subflow.
      
      This changeset introduces an infrastructure that allows
      any MPTCP subflow to schedule actions (MPTCP xmit) on
      others subflows without resorting to (multiple) process
      reschedule.
      
      A dummy NAPI instance is used instead. When MPTCP needs to
      trigger action an a different subflow, it enqueues the target
      subflow on the NAPI backlog and schedule such instance as needed.
      
      The dummy NAPI poll method walks the sockets backlog and tries
      to acquire the (BH) socket lock on each of them. If the socket
      is owned by the user space, the action will be completed by
      the sock release cb, otherwise push is started.
      
      This change leverages the delegated action infrastructure
      to avoid invoking the MPTCP worker to spool the pending data,
      when the packet scheduler picks a subflow other then the one
      currently processing the incoming MPTCP-level ack.
      
      Additionally we further refine the subflow selection
      invoking the packet scheduler for each chunk of data
      even inside __mptcp_subflow_push_pending().
      
      v1 -> v2:
       - fix possible UaF at shutdown time, resetting sock ops
         after removing the ulp context
      Reviewed-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      b19bc294
    • P
      mptcp: re-enable sndbuf autotune · 5cf92bba
      Paolo Abeni 提交于
      After commit 6e628cd3 ("mptcp: use mptcp release_cb for
      delayed tasks"), MPTCP never sets the flag bit SOCK_NOSPACE
      on its subflow. As a side effect, autotune never takes place,
      as it happens inside tcp_new_space(), which in turn is called
      only when the mentioned bit is set.
      
      Let's sendmsg() set the subflows NOSPACE bit when looking for
      more memory and use the subflow write_space callback to propagate
      the snd buf update and wake-up the user-space.
      
      Additionally, this allows dropping a bunch of duplicate code and
      makes the SNDBUF_LIMITED chrono relevant again for MPTCP subflows.
      
      Fixes: 6e628cd3 ("mptcp: use mptcp release_cb for delayed tasks")
      Reviewed-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      5cf92bba
    • P
      mptcp: always graft subflow socket to parent · 866f26f2
      Paolo Abeni 提交于
      Currently, incoming subflows link to the parent socket,
      while outgoing ones link to a per subflow socket. The latter
      is not really needed, except at the initial connect() time and
      for the first subflow.
      
      Always graft the outgoing subflow to the parent socket and
      free the unneeded ones early.
      
      This allows some code cleanup, reduces the amount of memory
      used and will simplify the next patch
      Reviewed-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      866f26f2
  10. 10 1月, 2021 2 次提交
    • G
      mptcp: add the incoming MP_PRIO support · 40453a5c
      Geliang Tang 提交于
      This patch added the incoming MP_PRIO logic:
      
      Added a flag named mp_prio in struct mptcp_options_received, to mark the
      MP_PRIO is received, and save the priority value to struct
      mptcp_options_received's backup member. Then invoke
      mptcp_pm_mp_prio_received with the receiving subsocket and the backup
      value.
      
      In mptcp_pm_mp_prio_received, get the subflow context according the input
      subsocket, and change the subflow's backup as the incoming priority value.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      40453a5c
    • G
      mptcp: add the outgoing MP_PRIO support · 06706542
      Geliang Tang 提交于
      This patch added the outgoing MP_PRIO logic:
      
      In mptcp_pm_nl_mp_prio_send_ack, find the related subflow and subsocket
      according to the input parameter addr. Save the input priority value to
      suflow's backup, then set subflow's send_mp_prio flag to true, and save
      the input priority value to suflow's request_bkup. Finally, send out a
      pure ACK on the related subsocket.
      
      In mptcp_established_options_mp_prio, check whether the subflow's
      send_mp_prio is set. If it is, this is the packet for sending MP_PRIO.
      So save subflow->request_bkup value to mptcp_out_options's backup, and
      change the option type to OPTION_MPTCP_PRIO.
      
      In mptcp_write_options, clear the send_mp_prio flag and send out the
      MP_PRIO suboption with mptcp_out_options's backup value.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      06706542
  11. 18 12月, 2020 1 次提交
  12. 15 12月, 2020 2 次提交
  13. 10 12月, 2020 7 次提交
    • P
      mptcp: link MPC subflow into msk only after accept · 5b950ff4
      Paolo Abeni 提交于
      Christoph reported the following splat:
      
      WARNING: CPU: 0 PID: 4615 at net/ipv4/inet_connection_sock.c:1031 inet_csk_listen_stop+0x8e8/0xad0 net/ipv4/inet_connection_sock.c:1031
      Modules linked in:
      CPU: 0 PID: 4615 Comm: syz-executor.4 Not tainted 5.9.0 #37
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      RIP: 0010:inet_csk_listen_stop+0x8e8/0xad0 net/ipv4/inet_connection_sock.c:1031
      Code: 03 00 00 00 e8 79 b2 3d ff e9 ad f9 ff ff e8 1f 76 ba fe be 02 00 00 00 4c 89 f7 e8 62 b2 3d ff e9 14 f9 ff ff e8 08 76 ba fe <0f> 0b e9 97 f8 ff ff e8 fc 75 ba fe be 03 00 00 00 4c 89 f7 e8 3f
      RSP: 0018:ffffc900037f7948 EFLAGS: 00010293
      RAX: ffff88810a349c80 RBX: ffff888114ee1b00 RCX: ffffffff827b14cd
      RDX: 0000000000000000 RSI: ffffffff827b1c38 RDI: 0000000000000005
      RBP: ffff88810a2a8000 R08: ffff88810a349c80 R09: fffff520006fef1f
      R10: 0000000000000003 R11: fffff520006fef1e R12: ffff888114ee2d00
      R13: dffffc0000000000 R14: 0000000000000001 R15: ffff888114ee1d68
      FS:  00007f2ac1945700(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffd44798bc0 CR3: 0000000109810002 CR4: 0000000000170ef0
      Call Trace:
       __tcp_close+0xd86/0x1110 net/ipv4/tcp.c:2433
       __mptcp_close_ssk+0x256/0x430 net/mptcp/protocol.c:1761
       __mptcp_destroy_sock+0x49b/0x770 net/mptcp/protocol.c:2127
       mptcp_close+0x62d/0x910 net/mptcp/protocol.c:2184
       inet_release+0xe9/0x1f0 net/ipv4/af_inet.c:434
       __sock_release+0xd2/0x280 net/socket.c:596
       sock_close+0x15/0x20 net/socket.c:1277
       __fput+0x276/0x960 fs/file_table.c:281
       task_work_run+0x109/0x1d0 kernel/task_work.c:151
       get_signal+0xe8f/0x1d40 kernel/signal.c:2561
       arch_do_signal+0x88/0x1b60 arch/x86/kernel/signal.c:811
       exit_to_user_mode_loop kernel/entry/common.c:161 [inline]
       exit_to_user_mode_prepare+0x9b/0xf0 kernel/entry/common.c:191
       syscall_exit_to_user_mode+0x22/0x150 kernel/entry/common.c:266
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7f2ac1254469
      Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ff 49 2b 00 f7 d8 64 89 01 48
      RSP: 002b:00007f2ac1944dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffbf RBX: 000000000069bf00 RCX: 00007f2ac1254469
      RDX: 0000000000000000 RSI: 0000000000008982 RDI: 0000000000000003
      RBP: 000000000069bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 000000000069bf0c
      R13: 00007ffeb53f178f R14: 00000000004668b0 R15: 0000000000000003
      
      After commit 0397c6d8 ("mptcp: keep unaccepted MPC subflow into
      join list"), the msk's workqueue and/or PM can touch the MPC
      subflow - and acquire its socket lock - even if it's still unaccepted.
      
      If the above event races with the relevant listener socket close, we
      can end-up with the above splat.
      
      This change addresses the issue delaying the MPC socket insertion
      in conn_list at accept time - that is, partially reverting the
      blamed commit.
      
      We must additionally ensure that mptcp_pm_fully_established()
      happens after accept() time, or the PM will not be able to
      handle properly such event - conn_list could be empty otherwise.
      
      In the receive path, we check the subflow list node to ensure
      it is out of the listener queue. Be sure client subflows do
      not match transiently such condition moving them into the join
      list earlier at creation time.
      
      Since we now have multiple mptcp_pm_fully_established() call sites
      from different code-paths, said helper can now race with itself.
      Use an additional PM status bit to avoid multiple notifications.
      Reported-by: NChristoph Paasch <cpaasch@apple.com>
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/103
      Fixes: 0397c6d8 ("mptcp: keep unaccepted MPC subflow into join list"),
      Reviewed-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b950ff4
    • G
      mptcp: rename add_addr_signal and mptcp_add_addr_status · 13ad9f01
      Geliang Tang 提交于
      Since the RM_ADDR signal had been reused with add_addr_signal, it's not
      suitable to call it add_addr_signal or mptcp_add_addr_status. So this
      patch renamed add_addr_signal to addr_signal, and renamed
      mptcp_add_addr_status to mptcp_addr_signal_status.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13ad9f01
    • G
      mptcp: drop rm_addr_signal flag · 42842a42
      Geliang Tang 提交于
      This patch reused add_addr_signal for the RM_ADDR announcing signal, by
      defining a new ADD_ADDR status named MPTCP_RM_ADDR_SIGNAL. Then the flag
      rm_addr_signal in PM could be dropped.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42842a42
    • G
      mptcp: add port parameter for mptcp_pm_announce_addr · 0f5c9e3f
      Geliang Tang 提交于
      This patch added a new parameter 'port' for mptcp_pm_announce_addr. If
      this parameter is true, we set the MPTCP_ADD_ADDR_PORT bit of the
      add_addr_signal. That means the announced address is added with a port
      number.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f5c9e3f
    • G
      mptcp: add the outgoing ADD_ADDR port support · 4a2777a8
      Geliang Tang 提交于
      This patch added a new add_addr_signal type named MPTCP_ADD_ADDR_PORT,
      to identify it is an address with port to be added.
      
      It also added a new parameter 'port' for both mptcp_add_addr_len and
      mptcp_pm_add_addr_signal.
      
      In mptcp_established_options_add_addr, we check whether the announced
      address is added with port. If it is, we put this port number to
      mptcp_out_options's port field.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a2777a8
    • G
      mptcp: use adding up size to get ADD_ADDR length · 2ec72fae
      Geliang Tang 提交于
      This patch uses adding up size to get the ADD_ADDR suboption length rather
      than returning the ADD_ADDR size constants.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ec72fae
    • G
      mptcp: add port support for ADD_ADDR suboption writing · 22fb85ff
      Geliang Tang 提交于
      In rfc8684, the length of ADD_ADDR suboption with IPv4 address and port
      is 18 octets, but mptcp_write_options is 32-bit aligned, so we need to
      pad it to 20 octets. All the other port related option lengths need to
      be added up 2 octets similarly.
      
      This patch added a new field 'port' in mptcp_out_options. When this
      field is set with a port number, we need to add up 4 octets for the
      ADD_ADDR suboption, and put the port number into the suboption.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22fb85ff
  14. 01 12月, 2020 1 次提交