1. 28 7月, 2021 3 次提交
    • J
      bpf, sockmap: Fix memleak on ingress msg enqueue · 9635720b
      John Fastabend 提交于
      If backlog handler is running during a tear down operation we may enqueue
      data on the ingress msg queue while tear down is trying to free it.
      
       sk_psock_backlog()
         sk_psock_handle_skb()
           skb_psock_skb_ingress()
             sk_psock_skb_ingress_enqueue()
               sk_psock_queue_msg(psock,msg)
                                                 spin_lock(ingress_lock)
                                                  sk_psock_zap_ingress()
                                                   _sk_psock_purge_ingerss_msg()
                                                    _sk_psock_purge_ingress_msg()
                                                  -- free ingress_msg list --
                                                 spin_unlock(ingress_lock)
                 spin_lock(ingress_lock)
                 list_add_tail(msg,ingress_msg) <- entry on list with no one
                                                   left to free it.
                 spin_unlock(ingress_lock)
      
      To fix we only enqueue from backlog if the ENABLED bit is set. The tear
      down logic clears the bit with ingress_lock set so we wont enqueue the
      msg in the last step.
      
      Fixes: 799aa7f9 ("skmsg: Avoid lock_sock() in sk_psock_backlog()")
      Signed-off-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
      Acked-by: NJakub Sitnicki <jakub@cloudflare.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20210727160500.1713554-4-john.fastabend@gmail.com
      9635720b
    • J
      bpf, sockmap: On cleanup we additionally need to remove cached skb · 476d9801
      John Fastabend 提交于
      Its possible if a socket is closed and the receive thread is under memory
      pressure it may have cached a skb. We need to ensure these skbs are
      free'd along with the normal ingress_skb queue.
      
      Before 799aa7f9 ("skmsg: Avoid lock_sock() in sk_psock_backlog()") tear
      down and backlog processing both had sock_lock for the common case of
      socket close or unhash. So it was not possible to have both running in
      parrallel so all we would need is the kfree in those kernels.
      
      But, latest kernels include the commit 799aa7f98d5e and this requires a
      bit more work. Without the ingress_lock guarding reading/writing the
      state->skb case its possible the tear down could run before the state
      update causing it to leak memory or worse when the backlog reads the state
      it could potentially run interleaved with the tear down and we might end up
      free'ing the state->skb from tear down side but already have the reference
      from backlog side. To resolve such races we wrap accesses in ingress_lock
      on both sides serializing tear down and backlog case. In both cases this
      only happens after an EAGAIN error case so having an extra lock in place
      is likely fine. The normal path will skip the locks.
      
      Note, we check state->skb before grabbing lock. This works because
      we can only enqueue with the mutex we hold already. Avoiding a race
      on adding state->skb after the check. And if tear down path is running
      that is also fine if the tear down path then removes state->skb we
      will simply set skb=NULL and the subsequent goto is skipped. This
      slight complication avoids locking in normal case.
      
      With this fix we no longer see this warning splat from tcp side on
      socket close when we hit the above case with redirect to ingress self.
      
      [224913.935822] WARNING: CPU: 3 PID: 32100 at net/core/stream.c:208 sk_stream_kill_queues+0x212/0x220
      [224913.935841] Modules linked in: fuse overlay bpf_preload x86_pkg_temp_thermal intel_uncore wmi_bmof squashfs sch_fq_codel efivarfs ip_tables x_tables uas xhci_pci ixgbe mdio xfrm_algo xhci_hcd wmi
      [224913.935897] CPU: 3 PID: 32100 Comm: fgs-bench Tainted: G          I       5.14.0-rc1alu+ #181
      [224913.935908] Hardware name: Dell Inc. Precision 5820 Tower/002KVM, BIOS 1.9.2 01/24/2019
      [224913.935914] RIP: 0010:sk_stream_kill_queues+0x212/0x220
      [224913.935923] Code: 8b 83 20 02 00 00 85 c0 75 20 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 df e8 2b 11 fe ff eb c3 0f 0b e9 7c ff ff ff 0f 0b eb ce <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 0f 1f 44 00 00 41 57 41
      [224913.935932] RSP: 0018:ffff88816271fd38 EFLAGS: 00010206
      [224913.935941] RAX: 0000000000000ae8 RBX: ffff88815acd5240 RCX: dffffc0000000000
      [224913.935948] RDX: 0000000000000003 RSI: 0000000000000ae8 RDI: ffff88815acd5460
      [224913.935954] RBP: ffff88815acd5460 R08: ffffffff955c0ae8 R09: fffffbfff2e6f543
      [224913.935961] R10: ffffffff9737aa17 R11: fffffbfff2e6f542 R12: ffff88815acd5390
      [224913.935967] R13: ffff88815acd5480 R14: ffffffff98d0c080 R15: ffffffff96267500
      [224913.935974] FS:  00007f86e6bd1700(0000) GS:ffff888451cc0000(0000) knlGS:0000000000000000
      [224913.935981] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [224913.935988] CR2: 000000c0008eb000 CR3: 00000001020e0005 CR4: 00000000003706e0
      [224913.935994] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [224913.936000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [224913.936007] Call Trace:
      [224913.936016]  inet_csk_destroy_sock+0xba/0x1f0
      [224913.936033]  __tcp_close+0x620/0x790
      [224913.936047]  tcp_close+0x20/0x80
      [224913.936056]  inet_release+0x8f/0xf0
      [224913.936070]  __sock_release+0x72/0x120
      [224913.936083]  sock_close+0x14/0x20
      
      Fixes: a136678c ("bpf: sk_msg, zap ingress queue on psock down")
      Signed-off-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
      Acked-by: NJakub Sitnicki <jakub@cloudflare.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20210727160500.1713554-3-john.fastabend@gmail.com
      476d9801
    • J
      bpf, sockmap: Zap ingress queues after stopping strparser · 343597d5
      John Fastabend 提交于
      We don't want strparser to run and pass skbs into skmsg handlers when
      the psock is null. We just sk_drop them in this case. When removing
      a live socket from map it means extra drops that we do not need to
      incur. Move the zap below strparser close to avoid this condition.
      
      This way we stop the stream parser first stopping it from processing
      packets and then delete the psock.
      
      Fixes: a136678c ("bpf: sk_msg, zap ingress queue on psock down")
      Signed-off-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
      Acked-by: NJakub Sitnicki <jakub@cloudflare.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20210727160500.1713554-2-john.fastabend@gmail.com
      343597d5
  2. 16 7月, 2021 5 次提交
  3. 14 7月, 2021 2 次提交
  4. 13 7月, 2021 2 次提交
    • X
      xdp, net: Fix use-after-free in bpf_xdp_link_release · 5acc7d3e
      Xuan Zhuo 提交于
      The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
      At this point, dev_xdp_uninstall() is called. Then xdp link will not be
      detached automatically when dev is released. But link->dev already
      points to dev, when xdp link is released, dev will still be accessed,
      but dev has been released.
      
      dev_get_by_index()        |
      link->dev = dev           |
                                |      rtnl_lock()
                                |      unregister_netdevice_many()
                                |          dev_xdp_uninstall()
                                |      rtnl_unlock()
      rtnl_lock();              |
      dev_xdp_attach_link()     |
      rtnl_unlock();            |
                                |      netdev_run_todo() // dev released
      bpf_xdp_link_release()    |
          /* access dev.        |
             use-after-free */  |
      
      [   45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
      [   45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
      [   45.968297]
      [   45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
      [   45.969222] Hardware name: linux,dummy-virt (DT)
      [   45.969795] Call trace:
      [   45.970106]  dump_backtrace+0x0/0x4c8
      [   45.970564]  show_stack+0x30/0x40
      [   45.970981]  dump_stack_lvl+0x120/0x18c
      [   45.971470]  print_address_description.constprop.0+0x74/0x30c
      [   45.972182]  kasan_report+0x1e8/0x200
      [   45.972659]  __asan_report_load8_noabort+0x2c/0x50
      [   45.973273]  bpf_xdp_link_release+0x3b8/0x3d0
      [   45.973834]  bpf_link_free+0xd0/0x188
      [   45.974315]  bpf_link_put+0x1d0/0x218
      [   45.974790]  bpf_link_release+0x3c/0x58
      [   45.975291]  __fput+0x20c/0x7e8
      [   45.975706]  ____fput+0x24/0x30
      [   45.976117]  task_work_run+0x104/0x258
      [   45.976609]  do_notify_resume+0x894/0xaf8
      [   45.977121]  work_pending+0xc/0x328
      [   45.977575]
      [   45.977775] The buggy address belongs to the page:
      [   45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
      [   45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
      [   45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
      [   45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      [   45.982259] page dumped because: kasan: bad access detected
      [   45.982948]
      [   45.983153] Memory state around the buggy address:
      [   45.983753]  ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   45.984645]  ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [   45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [   45.986419]                                               ^
      [   45.987112]  ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [   45.988006]  ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [   45.988895] ==================================================================
      [   45.989773] Disabling lock debugging due to kernel taint
      [   45.990552] Kernel panic - not syncing: panic_on_warn set ...
      [   45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G    B             5.13.0+ #22
      [   45.991929] Hardware name: linux,dummy-virt (DT)
      [   45.992448] Call trace:
      [   45.992753]  dump_backtrace+0x0/0x4c8
      [   45.993208]  show_stack+0x30/0x40
      [   45.993627]  dump_stack_lvl+0x120/0x18c
      [   45.994113]  dump_stack+0x1c/0x34
      [   45.994530]  panic+0x3a4/0x7d8
      [   45.994930]  end_report+0x194/0x198
      [   45.995380]  kasan_report+0x134/0x200
      [   45.995850]  __asan_report_load8_noabort+0x2c/0x50
      [   45.996453]  bpf_xdp_link_release+0x3b8/0x3d0
      [   45.997007]  bpf_link_free+0xd0/0x188
      [   45.997474]  bpf_link_put+0x1d0/0x218
      [   45.997942]  bpf_link_release+0x3c/0x58
      [   45.998429]  __fput+0x20c/0x7e8
      [   45.998833]  ____fput+0x24/0x30
      [   45.999247]  task_work_run+0x104/0x258
      [   45.999731]  do_notify_resume+0x894/0xaf8
      [   46.000236]  work_pending+0xc/0x328
      [   46.000697] SMP: stopping secondary CPUs
      [   46.001226] Dumping ftrace buffer:
      [   46.001663]    (ftrace buffer empty)
      [   46.002110] Kernel Offset: disabled
      [   46.002545] CPU features: 0x00000001,23202c00
      [   46.003080] Memory Limit: none
      
      Fixes: aa8d3a71 ("bpf, xdp: Add bpf_link-based XDP attachment API")
      Reported-by: NAbaci <abaci@linux.alibaba.com>
      Signed-off-by: NXuan Zhuo <xuanzhuo@linux.alibaba.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Reviewed-by: NDust Li <dust.li@linux.alibaba.com>
      Acked-by: NAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20210710031635.41649-1-xuanzhuo@linux.alibaba.com
      5acc7d3e
    • V
      ipv6: allocate enough headroom in ip6_finish_output2() · 5796015f
      Vasily Averin 提交于
      When TEE target mirrors traffic to another interface, sk_buff may
      not have enough headroom to be processed correctly.
      ip_finish_output2() detect this situation for ipv4 and allocates
      new skb with enogh headroom. However ipv6 lacks this logic in
      ip_finish_output2 and it leads to skb_under_panic:
      
       skbuff: skb_under_panic: text:ffffffffc0866ad4 len:96 put:24
       head:ffff97be85e31800 data:ffff97be85e317f8 tail:0x58 end:0xc0 dev:gre0
       ------------[ cut here ]------------
       kernel BUG at net/core/skbuff.c:110!
       invalid opcode: 0000 [#1] SMP PTI
       CPU: 2 PID: 393 Comm: kworker/2:2 Tainted: G           OE     5.13.0 #13
       Hardware name: Virtuozzo KVM, BIOS 1.11.0-2.vz7.4 04/01/2014
       Workqueue: ipv6_addrconf addrconf_dad_work
       RIP: 0010:skb_panic+0x48/0x4a
       Call Trace:
        skb_push.cold.111+0x10/0x10
        ipgre_header+0x24/0xf0 [ip_gre]
        neigh_connected_output+0xae/0xf0
        ip6_finish_output2+0x1a8/0x5a0
        ip6_output+0x5c/0x110
        nf_dup_ipv6+0x158/0x1000 [nf_dup_ipv6]
        tee_tg6+0x2e/0x40 [xt_TEE]
        ip6t_do_table+0x294/0x470 [ip6_tables]
        nf_hook_slow+0x44/0xc0
        nf_hook.constprop.34+0x72/0xe0
        ndisc_send_skb+0x20d/0x2e0
        ndisc_send_ns+0xd1/0x210
        addrconf_dad_work+0x3c8/0x540
        process_one_work+0x1d1/0x370
        worker_thread+0x30/0x390
        kthread+0x116/0x130
        ret_from_fork+0x22/0x30
      Signed-off-by: NVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5796015f
  5. 12 7月, 2021 3 次提交
    • X
      bpf, test: fix NULL pointer dereference on invalid expected_attach_type · 5e21bb4e
      Xuan Zhuo 提交于
      These two types of XDP progs (BPF_XDP_DEVMAP, BPF_XDP_CPUMAP) will not be
      executed directly in the driver, therefore we should also not directly
      run them from here. To run in these two situations, there must be further
      preparations done, otherwise these may cause a kernel panic.
      
      For more details, see also dev_xdp_attach().
      
        [   46.982479] BUG: kernel NULL pointer dereference, address: 0000000000000000
        [   46.984295] #PF: supervisor read access in kernel mode
        [   46.985777] #PF: error_code(0x0000) - not-present page
        [   46.987227] PGD 800000010dca4067 P4D 800000010dca4067 PUD 10dca6067 PMD 0
        [   46.989201] Oops: 0000 [#1] SMP PTI
        [   46.990304] CPU: 7 PID: 562 Comm: a.out Not tainted 5.13.0+ #44
        [   46.992001] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/24
        [   46.995113] RIP: 0010:___bpf_prog_run+0x17b/0x1710
        [   46.996586] Code: 49 03 14 cc e8 76 f6 fe ff e9 ad fe ff ff 0f b6 43 01 48 0f bf 4b 02 48 83 c3 08 89 c2 83 e0 0f c0 ea 04 02
        [   47.001562] RSP: 0018:ffffc900005afc58 EFLAGS: 00010246
        [   47.003115] RAX: 0000000000000000 RBX: ffffc9000023f068 RCX: 0000000000000000
        [   47.005163] RDX: 0000000000000000 RSI: 0000000000000079 RDI: ffffc900005afc98
        [   47.007135] RBP: 0000000000000000 R08: ffffc9000023f048 R09: c0000000ffffdfff
        [   47.009171] R10: 0000000000000001 R11: ffffc900005afb40 R12: ffffc900005afc98
        [   47.011172] R13: 0000000000000001 R14: 0000000000000001 R15: ffffffff825258a8
        [   47.013244] FS:  00007f04a5207580(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000
        [   47.015705] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [   47.017475] CR2: 0000000000000000 CR3: 0000000100182005 CR4: 0000000000770ee0
        [   47.019558] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        [   47.021595] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        [   47.023574] PKRU: 55555554
        [   47.024571] Call Trace:
        [   47.025424]  __bpf_prog_run32+0x32/0x50
        [   47.026296]  ? printk+0x53/0x6a
        [   47.027066]  ? ktime_get+0x39/0x90
        [   47.027895]  bpf_test_run.cold.28+0x23/0x123
        [   47.028866]  ? printk+0x53/0x6a
        [   47.029630]  bpf_prog_test_run_xdp+0x149/0x1d0
        [   47.030649]  __sys_bpf+0x1305/0x23d0
        [   47.031482]  __x64_sys_bpf+0x17/0x20
        [   47.032316]  do_syscall_64+0x3a/0x80
        [   47.033165]  entry_SYSCALL_64_after_hwframe+0x44/0xae
        [   47.034254] RIP: 0033:0x7f04a51364dd
        [   47.035133] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 48
        [   47.038768] RSP: 002b:00007fff8f9fc518 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
        [   47.040344] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f04a51364dd
        [   47.041749] RDX: 0000000000000048 RSI: 0000000020002a80 RDI: 000000000000000a
        [   47.043171] RBP: 00007fff8f9fc530 R08: 0000000002049300 R09: 0000000020000100
        [   47.044626] R10: 0000000000000004 R11: 0000000000000213 R12: 0000000000401070
        [   47.046088] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
        [   47.047579] Modules linked in:
        [   47.048318] CR2: 0000000000000000
        [   47.049120] ---[ end trace 7ad34443d5be719a ]---
        [   47.050273] RIP: 0010:___bpf_prog_run+0x17b/0x1710
        [   47.051343] Code: 49 03 14 cc e8 76 f6 fe ff e9 ad fe ff ff 0f b6 43 01 48 0f bf 4b 02 48 83 c3 08 89 c2 83 e0 0f c0 ea 04 02
        [   47.054943] RSP: 0018:ffffc900005afc58 EFLAGS: 00010246
        [   47.056068] RAX: 0000000000000000 RBX: ffffc9000023f068 RCX: 0000000000000000
        [   47.057522] RDX: 0000000000000000 RSI: 0000000000000079 RDI: ffffc900005afc98
        [   47.058961] RBP: 0000000000000000 R08: ffffc9000023f048 R09: c0000000ffffdfff
        [   47.060390] R10: 0000000000000001 R11: ffffc900005afb40 R12: ffffc900005afc98
        [   47.061803] R13: 0000000000000001 R14: 0000000000000001 R15: ffffffff825258a8
        [   47.063249] FS:  00007f04a5207580(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000
        [   47.065070] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [   47.066307] CR2: 0000000000000000 CR3: 0000000100182005 CR4: 0000000000770ee0
        [   47.067747] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        [   47.069217] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        [   47.070652] PKRU: 55555554
        [   47.071318] Kernel panic - not syncing: Fatal exception
        [   47.072854] Kernel Offset: disabled
        [   47.073683] ---[ end Kernel panic - not syncing: Fatal exception ]---
      
      Fixes: 92164774 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap")
      Fixes: fbee97fe ("bpf: Add support to attach bpf program to a devmap entry")
      Reported-by: NAbaci <abaci@linux.alibaba.com>
      Signed-off-by: NXuan Zhuo <xuanzhuo@linux.alibaba.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: NDust Li <dust.li@linux.alibaba.com>
      Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Acked-by: NDavid Ahern <dsahern@kernel.org>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20210708080409.73525-1-xuanzhuo@linux.alibaba.com
      5e21bb4e
    • N
      net: bridge: multicast: fix MRD advertisement router port marking race · 000b7287
      Nikolay Aleksandrov 提交于
      When an MRD advertisement is received on a bridge port with multicast
      snooping enabled, we mark it as a router port automatically, that
      includes adding that port to the router port list. The multicast lock
      protects that list, but it is not acquired in the MRD advertisement case
      leading to a race condition, we need to take it to fix the race.
      
      Cc: stable@vger.kernel.org
      Cc: linus.luessing@c0d3.blue
      Fixes: 4b3087c7 ("bridge: Snoop Multicast Router Advertisements")
      Signed-off-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      000b7287
    • N
      net: bridge: multicast: fix PIM hello router port marking race · 04bef83a
      Nikolay Aleksandrov 提交于
      When a PIM hello packet is received on a bridge port with multicast
      snooping enabled, we mark it as a router port automatically, that
      includes adding that port the router port list. The multicast lock
      protects that list, but it is not acquired in the PIM message case
      leading to a race condition, we need to take it to fix the race.
      
      Cc: stable@vger.kernel.org
      Fixes: 91b02d3d ("bridge: mcast: add router port on PIM hello message")
      Signed-off-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      04bef83a
  6. 10 7月, 2021 9 次提交
    • P
      mptcp: properly account bulk freed memory · ce599c51
      Paolo Abeni 提交于
      After commit 87952603 ("mptcp: protect the rx path with
      the msk socket spinlock") the rmem currently used by a given
      msk is really sk_rmem_alloc - rmem_released.
      
      The safety check in mptcp_data_ready() does not take the above
      in due account, as a result legit incoming data is kept in
      subflow receive queue with no reason, delaying or blocking
      MPTCP-level ack generation.
      
      This change addresses the issue introducing a new helper to fetch
      the rmem memory and using it as needed. Additionally add a MIB
      counter for the exceptional event described above - the peer is
      misbehaving.
      
      Finally, introduce the required annotation when rmem_released is
      updated.
      
      Fixes: 87952603 ("mptcp: protect the rx path with the msk socket spinlock")
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/211Signed-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>
      ce599c51
    • J
      mptcp: avoid processing packet if a subflow reset · 6787b7e3
      Jianguo Wu 提交于
      If check_fully_established() causes a subflow reset, it should not
      continue to process the packet in tcp_data_queue().
      Add a return value to mptcp_incoming_options(), and return false if a
      subflow has been reset, else return true. Then drop the packet in
      tcp_data_queue()/tcp_rcv_state_process() if mptcp_incoming_options()
      return false.
      
      Fixes: d5824847 ("mptcp: fix fallback for MP_JOIN subflows")
      Signed-off-by: NJianguo Wu <wujianguo@chinatelecom.cn>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6787b7e3
    • J
      mptcp: fix syncookie process if mptcp can not_accept new subflow · 8547ea5f
      Jianguo Wu 提交于
      Lots of "TCP: tcp_fin: Impossible, sk->sk_state=7" in client side
      when doing stress testing using wrk and webfsd.
      
      There are at least two cases may trigger this warning:
      1.mptcp is in syncookie, and server recv MP_JOIN SYN request,
        in subflow_check_req(), the mptcp_can_accept_new_subflow()
        return false, so subflow_init_req_cookie_join_save() isn't
        called, i.e. not store the data present in the MP_JOIN syn
        request and the random nonce in hash table - join_entries[],
        but still send synack. When recv 3rd-ack,
        mptcp_token_join_cookie_init_state() will return false, and
        3rd-ack is dropped, then if mptcp conn is closed by client,
        client will send a DATA_FIN and a MPTCP FIN, the DATA_FIN
        doesn't have MP_CAPABLE or MP_JOIN,
        so mptcp_subflow_init_cookie_req() will return 0, and pass
        the cookie check, MP_JOIN request is fallback to normal TCP.
        Server will send a TCP FIN if closed, in client side,
        when process TCP FIN, it will do reset, the code path is:
          tcp_data_queue()->mptcp_incoming_options()
            ->check_fully_established()->mptcp_subflow_reset().
        mptcp_subflow_reset() will set sock state to TCP_CLOSE,
        so tcp_fin will hit TCP_CLOSE, and print the warning.
      
      2.mptcp is in syncookie, and server recv 3rd-ack, in
        mptcp_subflow_init_cookie_req(), mptcp_can_accept_new_subflow()
        return false, and subflow_req->mp_join is not set to 1,
        so in subflow_syn_recv_sock() will not reset the MP_JOIN
        subflow, but fallback to normal TCP, and then the same thing
        happens when server will send a TCP FIN if closed.
      
      For case1, subflow_check_req() return -EPERM,
      then tcp_conn_request() will drop MP_JOIN SYN.
      
      For case2, let subflow_syn_recv_sock() call
      mptcp_can_accept_new_subflow(), and do fatal fallback, send reset.
      
      Fixes: 9466a1cc ("mptcp: enable JOIN requests even if cookies are in use")
      Signed-off-by: NJianguo Wu <wujianguo@chinatelecom.cn>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8547ea5f
    • J
      mptcp: remove redundant req destruct in subflow_check_req() · 030d37bd
      Jianguo Wu 提交于
      In subflow_check_req(), if subflow sport is mismatch, will put msk,
      destroy token, and destruct req, then return -EPERM, which can be
      done by subflow_req_destructor() via:
      
        tcp_conn_request()
          |--__reqsk_free()
            |--subflow_req_destructor()
      
      So we should remove these redundant code, otherwise will call
      tcp_v4_reqsk_destructor() twice, and may double free
      inet_rsk(req)->ireq_opt.
      
      Fixes: 5bc56388 ("mptcp: add port number check for MP_JOIN")
      Signed-off-by: NJianguo Wu <wujianguo@chinatelecom.cn>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      030d37bd
    • J
      mptcp: fix warning in __skb_flow_dissect() when do syn cookie for subflow join · 0c71929b
      Jianguo Wu 提交于
      I did stress test with wrk[1] and webfsd[2] with the assistance of
      mptcp-tools[3]:
      
        Server side:
            ./use_mptcp.sh webfsd -4 -R /tmp/ -p 8099
        Client side:
            ./use_mptcp.sh wrk -c 200 -d 30 -t 4 http://192.168.174.129:8099/
      
      and got the following warning message:
      
      [   55.552626] TCP: request_sock_subflow: Possible SYN flooding on port 8099. Sending cookies.  Check SNMP counters.
      [   55.553024] ------------[ cut here ]------------
      [   55.553027] WARNING: CPU: 0 PID: 10 at net/core/flow_dissector.c:984 __skb_flow_dissect+0x280/0x1650
      ...
      [   55.553117] CPU: 0 PID: 10 Comm: ksoftirqd/0 Not tainted 5.12.0+ #18
      [   55.553121] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
      [   55.553124] RIP: 0010:__skb_flow_dissect+0x280/0x1650
      ...
      [   55.553133] RSP: 0018:ffffb79580087770 EFLAGS: 00010246
      [   55.553137] RAX: 0000000000000000 RBX: ffffffff8ddb58e0 RCX: ffffb79580087888
      [   55.553139] RDX: ffffffff8ddb58e0 RSI: ffff8f7e4652b600 RDI: 0000000000000000
      [   55.553141] RBP: ffffb79580087858 R08: 0000000000000000 R09: 0000000000000008
      [   55.553143] R10: 000000008c622965 R11: 00000000d3313a5b R12: ffff8f7e4652b600
      [   55.553146] R13: ffff8f7e465c9062 R14: 0000000000000000 R15: ffffb79580087888
      [   55.553149] FS:  0000000000000000(0000) GS:ffff8f7f75e00000(0000) knlGS:0000000000000000
      [   55.553152] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   55.553154] CR2: 00007f73d1d19000 CR3: 0000000135e10004 CR4: 00000000003706f0
      [   55.553160] Call Trace:
      [   55.553166]  ? __sha256_final+0x67/0xd0
      [   55.553173]  ? sha256+0x7e/0xa0
      [   55.553177]  __skb_get_hash+0x57/0x210
      [   55.553182]  subflow_init_req_cookie_join_save+0xac/0xc0
      [   55.553189]  subflow_check_req+0x474/0x550
      [   55.553195]  ? ip_route_output_key_hash+0x67/0x90
      [   55.553200]  ? xfrm_lookup_route+0x1d/0xa0
      [   55.553207]  subflow_v4_route_req+0x8e/0xd0
      [   55.553212]  tcp_conn_request+0x31e/0xab0
      [   55.553218]  ? selinux_socket_sock_rcv_skb+0x116/0x210
      [   55.553224]  ? tcp_rcv_state_process+0x179/0x6d0
      [   55.553229]  tcp_rcv_state_process+0x179/0x6d0
      [   55.553235]  tcp_v4_do_rcv+0xaf/0x220
      [   55.553239]  tcp_v4_rcv+0xce4/0xd80
      [   55.553243]  ? ip_route_input_rcu+0x246/0x260
      [   55.553248]  ip_protocol_deliver_rcu+0x35/0x1b0
      [   55.553253]  ip_local_deliver_finish+0x44/0x50
      [   55.553258]  ip_local_deliver+0x6c/0x110
      [   55.553262]  ? ip_rcv_finish_core.isra.19+0x5a/0x400
      [   55.553267]  ip_rcv+0xd1/0xe0
      ...
      
      After debugging, I found in __skb_flow_dissect(), skb->dev and skb->sk
      are both NULL, then net is NULL, and trigger WARN_ON_ONCE(!net),
      actually net is always NULL in this code path, as skb->dev is set to
      NULL in tcp_v4_rcv(), and skb->sk is never set.
      
      Code snippet in __skb_flow_dissect() that trigger warning:
        975         if (skb) {
        976                 if (!net) {
        977                         if (skb->dev)
        978                                 net = dev_net(skb->dev);
        979                         else if (skb->sk)
        980                                 net = sock_net(skb->sk);
        981                 }
        982         }
        983
        984         WARN_ON_ONCE(!net);
      
      So, using seq and transport header derived hash.
      
      [1] https://github.com/wg/wrk
      [2] https://github.com/ourway/webfsd
      [3] https://github.com/pabeni/mptcp-tools
      
      Fixes: 9466a1cc ("mptcp: enable JOIN requests even if cookies are in use")
      Suggested-by: NPaolo Abeni <pabeni@redhat.com>
      Suggested-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NJianguo Wu <wujianguo@chinatelecom.cn>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c71929b
    • H
      net: ip_tunnel: fix mtu calculation for ETHER tunnel devices · 9992a078
      Hangbin Liu 提交于
      Commit 28e104d0 ("net: ip_tunnel: fix mtu calculation") removed
      dev->hard_header_len subtraction when calculate MTU for tunnel devices
      as there is an overhead for device that has header_ops.
      
      But there are ETHER tunnel devices, like gre_tap or erspan, which don't
      have header_ops but set dev->hard_header_len during setup. This makes
      pkts greater than (MTU - ETH_HLEN) could not be xmited. Fix it by
      subtracting the ETHER tunnel devices' dev->hard_header_len for MTU
      calculation.
      
      Fixes: 28e104d0 ("net: ip_tunnel: fix mtu calculation")
      Reported-by: NJianlin Shi <jishi@redhat.com>
      Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9992a078
    • A
      net: do not reuse skbuff allocated from skbuff_fclone_cache in the skb cache · 28b34f01
      Antoine Tenart 提交于
      Some socket buffers allocated in the fclone cache (in __alloc_skb) can
      end-up in the following path[1]:
      
      napi_skb_finish
        __kfree_skb_defer
          napi_skb_cache_put
      
      The issue is napi_skb_cache_put is not fclone friendly and will put
      those skbuff in the skb cache to be reused later, although this cache
      only expects skbuff allocated from skbuff_head_cache. When this happens
      the skbuff is eventually freed using the wrong origin cache, and we can
      see traces similar to:
      
      [ 1223.947534] cache_from_obj: Wrong slab cache. skbuff_head_cache but object is from skbuff_fclone_cache
      [ 1223.948895] WARNING: CPU: 3 PID: 0 at mm/slab.h:442 kmem_cache_free+0x251/0x3e0
      [ 1223.950211] Modules linked in:
      [ 1223.950680] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.13.0+ #474
      [ 1223.951587] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-3.fc34 04/01/2014
      [ 1223.953060] RIP: 0010:kmem_cache_free+0x251/0x3e0
      
      Leading sometimes to other memory related issues.
      
      Fix this by using __kfree_skb for fclone skbuff, similar to what is done
      the other place __kfree_skb_defer is called.
      
      [1] At least in setups using veth pairs and tunnels. Building a kernel
          with KASAN we can for example see packets allocated in
          sk_stream_alloc_skb hit the above path and later the issue arises
          when the skbuff is reused.
      
      Fixes: 9243adfc ("skbuff: queue NAPI_MERGED_FREE skbs into NAPI cache instead of freeing")
      Cc: Alexander Lobakin <alobakin@pm.me>
      Signed-off-by: NAntoine Tenart <atenart@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28b34f01
    • T
      tcp: call sk_wmem_schedule before sk_mem_charge in zerocopy path · 358ed624
      Talal Ahmad 提交于
      sk_wmem_schedule makes sure that sk_forward_alloc has enough
      bytes for charging that is going to be done by sk_mem_charge.
      
      In the transmit zerocopy path, there is sk_mem_charge but there was
      no call to sk_wmem_schedule. This change adds that call.
      
      Without this call to sk_wmem_schedule, sk_forward_alloc can go
      negetive which is a bug because sk_forward_alloc is a per-socket
      space that has been forward charged so this can't be negative.
      
      Fixes: f214f915 ("tcp: enable MSG_ZEROCOPY")
      Signed-off-by: NTalal Ahmad <talalahmad@google.com>
      Reviewed-by: NWillem de Bruijn <willemb@google.com>
      Reviewed-by: NWei Wang <weiwan@google.com>
      Reviewed-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      358ed624
    • A
      net: send SYNACK packet with accepted fwmark · 43b90bfa
      Alexander Ovechkin 提交于
      commit e05a90ec ("net: reflect mark on tcp syn ack packets")
      fixed IPv4 only.
      
      This part is for the IPv6 side.
      
      Fixes: e05a90ec ("net: reflect mark on tcp syn ack packets")
      Signed-off-by: NAlexander Ovechkin <ovov@yandex-team.ru>
      Acked-by: NDmitry Yakunin <zeil@yandex-team.ru>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      43b90bfa
  7. 09 7月, 2021 16 次提交
反馈
建议
客服 返回
顶部