1. 16 5月, 2018 5 次提交
  2. 14 5月, 2018 1 次提交
  3. 12 5月, 2018 4 次提交
    • R
      net sched actions: fix refcnt leak in skbmod · a52956df
      Roman Mashak 提交于
      When application fails to pass flags in netlink TLV when replacing
      existing skbmod action, the kernel will leak refcnt:
      
      $ tc actions get action skbmod index 1
      total acts 0
      
              action order 0: skbmod pipe set smac 00:11:22:33:44:55
               index 1 ref 1 bind 0
      
      For example, at this point a buggy application replaces the action with
      index 1 with new smac 00:aa:22:33:44:55, it fails because of zero flags,
      however refcnt gets bumped:
      
      $ tc actions get actions skbmod index 1
      total acts 0
      
              action order 0: skbmod pipe set smac 00:11:22:33:44:55
               index 1 ref 2 bind 0
      $
      
      Tha patch fixes this by calling tcf_idr_release() on existing actions.
      
      Fixes: 86da71b5 ("net_sched: Introduce skbmod action")
      Signed-off-by: NRoman Mashak <mrv@mojatatu.com>
      Acked-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a52956df
    • J
      net: sched: fix error path in tcf_proto_create() when modules are not configured · d68d75fd
      Jiri Pirko 提交于
      In case modules are not configured, error out when tp->ops is null
      and prevent later null pointer dereference.
      
      Fixes: 33a48927 ("sched: push TC filter protocol creation into a separate function")
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d68d75fd
    • R
      net sched actions: fix invalid pointer dereferencing if skbedit flags missing · af5d0184
      Roman Mashak 提交于
      When application fails to pass flags in netlink TLV for a new skbedit action,
      the kernel results in the following oops:
      
      [    8.307732] BUG: unable to handle kernel paging request at 0000000000021130
      [    8.309167] PGD 80000000193d1067 P4D 80000000193d1067 PUD 180e0067 PMD 0
      [    8.310595] Oops: 0000 [#1] SMP PTI
      [    8.311334] Modules linked in: kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper serio_raw
      [    8.314190] CPU: 1 PID: 397 Comm: tc Not tainted 4.17.0-rc3+ #357
      [    8.315252] RIP: 0010:__tcf_idr_release+0x33/0x140
      [    8.316203] RSP: 0018:ffffa0718038f840 EFLAGS: 00010246
      [    8.317123] RAX: 0000000000000001 RBX: 0000000000021100 RCX: 0000000000000000
      [    8.319831] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000021100
      [    8.321181] RBP: 0000000000000000 R08: 000000000004adf8 R09: 0000000000000122
      [    8.322645] R10: 0000000000000000 R11: ffffffff9e5b01ed R12: 0000000000000000
      [    8.324157] R13: ffffffff9e0d3cc0 R14: 0000000000000000 R15: 0000000000000000
      [    8.325590] FS:  00007f591292e700(0000) GS:ffff8fcf5bc40000(0000) knlGS:0000000000000000
      [    8.327001] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    8.327987] CR2: 0000000000021130 CR3: 00000000180e6004 CR4: 00000000001606a0
      [    8.329289] Call Trace:
      [    8.329735]  tcf_skbedit_init+0xa7/0xb0
      [    8.330423]  tcf_action_init_1+0x362/0x410
      [    8.331139]  ? try_to_wake_up+0x44/0x430
      [    8.331817]  tcf_action_init+0x103/0x190
      [    8.332511]  tc_ctl_action+0x11a/0x220
      [    8.333174]  rtnetlink_rcv_msg+0x23d/0x2e0
      [    8.333902]  ? _cond_resched+0x16/0x40
      [    8.334569]  ? __kmalloc_node_track_caller+0x5b/0x2c0
      [    8.335440]  ? rtnl_calcit.isra.31+0xf0/0xf0
      [    8.336178]  netlink_rcv_skb+0xdb/0x110
      [    8.336855]  netlink_unicast+0x167/0x220
      [    8.337550]  netlink_sendmsg+0x2a7/0x390
      [    8.338258]  sock_sendmsg+0x30/0x40
      [    8.338865]  ___sys_sendmsg+0x2c5/0x2e0
      [    8.339531]  ? pagecache_get_page+0x27/0x210
      [    8.340271]  ? filemap_fault+0xa2/0x630
      [    8.340943]  ? page_add_file_rmap+0x108/0x200
      [    8.341732]  ? alloc_set_pte+0x2aa/0x530
      [    8.342573]  ? finish_fault+0x4e/0x70
      [    8.343332]  ? __handle_mm_fault+0xbc1/0x10d0
      [    8.344337]  ? __sys_sendmsg+0x53/0x80
      [    8.345040]  __sys_sendmsg+0x53/0x80
      [    8.345678]  do_syscall_64+0x4f/0x100
      [    8.346339]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [    8.347206] RIP: 0033:0x7f591191da67
      [    8.347831] RSP: 002b:00007fff745abd48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      [    8.349179] RAX: ffffffffffffffda RBX: 00007fff745abe70 RCX: 00007f591191da67
      [    8.350431] RDX: 0000000000000000 RSI: 00007fff745abdc0 RDI: 0000000000000003
      [    8.351659] RBP: 000000005af35251 R08: 0000000000000001 R09: 0000000000000000
      [    8.352922] R10: 00000000000005f1 R11: 0000000000000246 R12: 0000000000000000
      [    8.354183] R13: 00007fff745afed0 R14: 0000000000000001 R15: 00000000006767c0
      [    8.355400] Code: 41 89 d4 53 89 f5 48 89 fb e8 aa 20 fd ff 85 c0 0f 84 ed 00
      00 00 48 85 db 0f 84 cf 00 00 00 40 84 ed 0f 85 cd 00 00 00 45 84 e4 <8b> 53 30
      74 0d 85 d2 b8 ff ff ff ff 0f 8f b3 00 00 00 8b 43 2c
      [    8.358699] RIP: __tcf_idr_release+0x33/0x140 RSP: ffffa0718038f840
      [    8.359770] CR2: 0000000000021130
      [    8.360438] ---[ end trace 60c66be45dfc14f0 ]---
      
      The caller calls action's ->init() and passes pointer to "struct tc_action *a",
      which later may be initialized to point at the existing action, otherwise
      "struct tc_action *a" is still invalid, and therefore dereferencing it is an
      error as happens in tcf_idr_release, where refcnt is decremented.
      
      So in case of missing flags tcf_idr_release must be called only for
      existing actions.
      
      v2:
          - prepare patch for net tree
      
      Fixes: 5e1567ae ("net sched: skbedit action fix late binding")
      Signed-off-by: NRoman Mashak <mrv@mojatatu.com>
      Acked-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af5d0184
    • A
      ipv4: fix memory leaks in udp_sendmsg, ping_v4_sendmsg · 1b97013b
      Andrey Ignatov 提交于
      Fix more memory leaks in ip_cmsg_send() callers. Part of them were fixed
      earlier in 91948309.
      
      * udp_sendmsg one was there since the beginning when linux sources were
        first added to git;
      * ping_v4_sendmsg one was copy/pasted in c319b4d7.
      
      Whenever return happens in udp_sendmsg() or ping_v4_sendmsg() IP options
      have to be freed if they were allocated previously.
      
      Add label so that future callers (if any) can use it instead of kfree()
      before return that is easy to forget.
      
      Fixes: c319b4d7 (net: ipv4: add IPPROTO_ICMP socket kind)
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b97013b
  4. 11 5月, 2018 11 次提交
  5. 10 5月, 2018 3 次提交
    • Y
      tipc: eliminate KMSAN uninit-value in strcmp complaint · 94f6a80c
      Ying Xue 提交于
      When we get link properties through netlink interface with
      tipc_nl_node_get_link(), we don't validate TIPC_NLA_LINK_NAME
      attribute at all, instead we directly use it. As a consequence,
      KMSAN detected the TIPC_NLA_LINK_NAME attribute was an uninitialized
      value, and then posted the following complaint:
      
      ==================================================================
      BUG: KMSAN: uninit-value in strcmp+0xf7/0x160 lib/string.c:329
      CPU: 1 PID: 4527 Comm: syz-executor655 Not tainted 4.16.0+ #87
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:17 [inline]
        dump_stack+0x185/0x1d0 lib/dump_stack.c:53
        kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
        __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
        strcmp+0xf7/0x160 lib/string.c:329
        tipc_nl_node_get_link+0x220/0x6f0 net/tipc/node.c:1881
        genl_family_rcv_msg net/netlink/genetlink.c:599 [inline]
        genl_rcv_msg+0x1686/0x1810 net/netlink/genetlink.c:624
        netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2447
        genl_rcv+0x63/0x80 net/netlink/genetlink.c:635
        netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
        netlink_unicast+0x166b/0x1740 net/netlink/af_netlink.c:1337
        netlink_sendmsg+0x1048/0x1310 net/netlink/af_netlink.c:1900
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg net/socket.c:640 [inline]
        ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
        __sys_sendmsg net/socket.c:2080 [inline]
        SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
        SyS_sendmsg+0x54/0x80 net/socket.c:2087
        do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x445589
      RSP: 002b:00007fb7ee66cdb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445589
      RDX: 0000000000000000 RSI: 0000000020023000 RDI: 0000000000000003
      RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007fffa2bf3f3f R14: 00007fb7ee66d9c0 R15: 0000000000000001
      
      Uninit was created at:
        kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
        kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
        kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
        kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
        slab_post_alloc_hook mm/slab.h:445 [inline]
        slab_alloc_node mm/slub.c:2737 [inline]
        __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
        __kmalloc_reserve net/core/skbuff.c:138 [inline]
        __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
        alloc_skb include/linux/skbuff.h:984 [inline]
        netlink_alloc_large_skb net/netlink/af_netlink.c:1183 [inline]
        netlink_sendmsg+0x9a6/0x1310 net/netlink/af_netlink.c:1875
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg net/socket.c:640 [inline]
        ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
        __sys_sendmsg net/socket.c:2080 [inline]
        SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
        SyS_sendmsg+0x54/0x80 net/socket.c:2087
        do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      ==================================================================
      
      To quiet the complaint, TIPC_NLA_LINK_NAME attribute has been
      validated in tipc_nl_node_get_link() before it's used.
      
      Reported-by: syzbot+df0257c92ffd4fcc58cd@syzkaller.appspotmail.com
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94f6a80c
    • S
      net/9p: correct some comment errors in 9p file system code · 4a026da9
      Sun Lianwen 提交于
      There are follow comment errors:
      1 The function name is wrong in p9_release_pages() comment.
      2 The function name and variable name is wrong in p9_poll_workfn() comment.
      3 There is no variable dm_mr and lkey in struct p9_trans_rdma.
      4 The function name is wrong in rdma_create_trans() comment.
      5 There is no variable initialized in struct virtio_chan.
      6 The variable name is wrong in p9_virtio_zc_request() comment.
      Signed-off-by: NSun Lianwen <sunlw.fnst@cn.fujitsu.com>
      Reviewed-by: NRandy Dunlap <rdunlap@infradead.org>
      Reviewed-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a026da9
    • I
      libceph: add osd_req_op_extent_osd_data_bvecs() · 0010f705
      Ilya Dryomov 提交于
      ... and store num_bvecs for client code's convenience.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: N"Yan, Zheng" <zyan@redhat.com>
      0010f705
  6. 08 5月, 2018 6 次提交
    • E
      llc: better deal with too small mtu · 2c5d5b13
      Eric Dumazet 提交于
      syzbot loves to set very small mtu on devices, since it brings joy.
      We must make llc_ui_sendmsg() fool proof.
      
      usercopy: Kernel memory overwrite attempt detected to wrapped address (offset 0, size 18446612139802320068)!
      
      kernel BUG at mm/usercopy.c:100!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 0 PID: 17464 Comm: syz-executor1 Not tainted 4.17.0-rc3+ #36
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:usercopy_abort+0xbb/0xbd mm/usercopy.c:88
      RSP: 0018:ffff8801868bf800 EFLAGS: 00010282
      RAX: 000000000000006c RBX: ffffffff87d2fb00 RCX: 0000000000000000
      RDX: 000000000000006c RSI: ffffffff81610731 RDI: ffffed0030d17ef6
      RBP: ffff8801868bf858 R08: ffff88018daa4200 R09: ffffed003b5c4fb0
      R10: ffffed003b5c4fb0 R11: ffff8801dae27d87 R12: ffffffff87d2f8e0
      R13: ffffffff87d2f7a0 R14: ffffffff87d2f7a0 R15: ffffffff87d2f7a0
      FS:  00007f56a14ac700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b2bc21000 CR3: 00000001abeb1000 CR4: 00000000001426f0
      DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000030602
      Call Trace:
       check_bogus_address mm/usercopy.c:153 [inline]
       __check_object_size+0x5d9/0x5d9 mm/usercopy.c:256
       check_object_size include/linux/thread_info.h:108 [inline]
       check_copy_size include/linux/thread_info.h:139 [inline]
       copy_from_iter_full include/linux/uio.h:121 [inline]
       memcpy_from_msg include/linux/skbuff.h:3305 [inline]
       llc_ui_sendmsg+0x4b1/0x1530 net/llc/af_llc.c:941
       sock_sendmsg_nosec net/socket.c:629 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:639
       __sys_sendto+0x3d7/0x670 net/socket.c:1789
       __do_sys_sendto net/socket.c:1801 [inline]
       __se_sys_sendto net/socket.c:1797 [inline]
       __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
       do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x455979
      RSP: 002b:00007f56a14abc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 00007f56a14ac6d4 RCX: 0000000000455979
      RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000018
      RBP: 000000000072bea0 R08: 00000000200012c0 R09: 0000000000000010
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 0000000000000548 R14: 00000000006fbf60 R15: 0000000000000000
      Code: 55 c0 e8 c0 55 bb ff ff 75 c8 48 8b 55 c0 4d 89 f9 ff 75 d0 4d 89 e8 48 89 d9 4c 89 e6 41 56 48 c7 c7 80 fa d2 87 e8 a0 0b a3 ff <0f> 0b e8 95 55 bb ff e8 c0 a8 f7 ff 8b 95 14 ff ff ff 4d 89 e8
      RIP: usercopy_abort+0xbb/0xbd mm/usercopy.c:88 RSP: ffff8801868bf800
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c5d5b13
    • G
      trivial: fix inconsistent help texts · a9f71d0d
      Georg Hofmann 提交于
      This patch removes "experimental" from the help text where depends on
      CONFIG_EXPERIMENTAL was already removed.
      Signed-off-by: NGeorg Hofmann <georg@hofmannsweb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a9f71d0d
    • A
      net/tls: Fix connection stall on partial tls record · 080324c3
      Andre Tomt 提交于
      In the case of writing a partial tls record we forgot to clear the
      ctx->in_tcp_sendpages flag, causing some connections to stall.
      
      Fixes: c212d2c7 ("net/tls: Don't recursively call push_record during tls_write_space callbacks")
      Signed-off-by: NAndre Tomt <andre@tomt.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      080324c3
    • E
      tls: fix use after free in tls_sk_proto_close · 98f0a395
      Eric Dumazet 提交于
      syzbot reported a use-after-free in tls_sk_proto_close
      
      Add a boolean value to cleanup a bit this function.
      
      BUG: KASAN: use-after-free in tls_sk_proto_close+0x8ab/0x9c0 net/tls/tls_main.c:297
      Read of size 1 at addr ffff8801ae40a858 by task syz-executor363/4503
      
      CPU: 0 PID: 4503 Comm: syz-executor363 Not tainted 4.17.0-rc3+ #34
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1b9/0x294 lib/dump_stack.c:113
       print_address_description+0x6c/0x20b mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
       __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
       tls_sk_proto_close+0x8ab/0x9c0 net/tls/tls_main.c:297
       inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
       inet6_release+0x50/0x70 net/ipv6/af_inet6.c:460
       sock_release+0x96/0x1b0 net/socket.c:594
       sock_close+0x16/0x20 net/socket.c:1149
       __fput+0x34d/0x890 fs/file_table.c:209
       ____fput+0x15/0x20 fs/file_table.c:243
       task_work_run+0x1e4/0x290 kernel/task_work.c:113
       exit_task_work include/linux/task_work.h:22 [inline]
       do_exit+0x1aee/0x2730 kernel/exit.c:865
       do_group_exit+0x16f/0x430 kernel/exit.c:968
       get_signal+0x886/0x1960 kernel/signal.c:2469
       do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
       exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
       prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
       do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4457b9
      RSP: 002b:00007fdf4d766da8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
      RAX: fffffffffffffe00 RBX: 00000000006dac3c RCX: 00000000004457b9
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000006dac3c
      RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac38
      R13: 3692738801137283 R14: 6bf92c39443c4c1d R15: 0000000000000006
      
      Allocated by task 4498:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
       kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
       kmalloc include/linux/slab.h:512 [inline]
       kzalloc include/linux/slab.h:701 [inline]
       create_ctx net/tls/tls_main.c:521 [inline]
       tls_init+0x1f9/0xb00 net/tls/tls_main.c:633
       tcp_set_ulp+0x1bc/0x520 net/ipv4/tcp_ulp.c:153
       do_tcp_setsockopt.isra.39+0x44a/0x2600 net/ipv4/tcp.c:2588
       tcp_setsockopt+0xc1/0xe0 net/ipv4/tcp.c:2893
       sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3039
       __sys_setsockopt+0x1bd/0x390 net/socket.c:1903
       __do_sys_setsockopt net/socket.c:1914 [inline]
       __se_sys_setsockopt net/socket.c:1911 [inline]
       __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
       do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 4503:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
       kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
       __cache_free mm/slab.c:3498 [inline]
       kfree+0xd9/0x260 mm/slab.c:3813
       tls_sw_free_resources+0x2a3/0x360 net/tls/tls_sw.c:1037
       tls_sk_proto_close+0x67c/0x9c0 net/tls/tls_main.c:288
       inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
       inet6_release+0x50/0x70 net/ipv6/af_inet6.c:460
       sock_release+0x96/0x1b0 net/socket.c:594
       sock_close+0x16/0x20 net/socket.c:1149
       __fput+0x34d/0x890 fs/file_table.c:209
       ____fput+0x15/0x20 fs/file_table.c:243
       task_work_run+0x1e4/0x290 kernel/task_work.c:113
       exit_task_work include/linux/task_work.h:22 [inline]
       do_exit+0x1aee/0x2730 kernel/exit.c:865
       do_group_exit+0x16f/0x430 kernel/exit.c:968
       get_signal+0x886/0x1960 kernel/signal.c:2469
       do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
       exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
       prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
       do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8801ae40a800
       which belongs to the cache kmalloc-256 of size 256
      The buggy address is located 88 bytes inside of
       256-byte region [ffff8801ae40a800, ffff8801ae40a900)
      The buggy address belongs to the page:
      page:ffffea0006b90280 count:1 mapcount:0 mapping:ffff8801ae40a080 index:0x0
      flags: 0x2fffc0000000100(slab)
      raw: 02fffc0000000100 ffff8801ae40a080 0000000000000000 000000010000000c
      raw: ffffea0006bea9e0 ffffea0006bc94a0 ffff8801da8007c0 0000000000000000
      page dumped because: kasan: bad access detected
      
      Fixes: dd0bed16 ("tls: support for Inline tls record")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Atul Gupta <atul.gupta@chelsio.com>
      Cc: Steve Wise <swise@opengridcomputing.com>
      Cc: Ilya Lesokhin <ilyal@mellanox.com>
      Cc: Aviad Yehezkel <aviadye@mellanox.com>
      Cc: Dave Watson <davejwatson@fb.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98f0a395
    • X
      sctp: delay the authentication for the duplicated cookie-echo chunk · 59d8d443
      Xin Long 提交于
      Now sctp only delays the authentication for the normal cookie-echo
      chunk by setting chunk->auth_chunk in sctp_endpoint_bh_rcv(). But
      for the duplicated one with auth, in sctp_assoc_bh_rcv(), it does
      authentication first based on the old asoc, which will definitely
      fail due to the different auth info in the old asoc.
      
      The duplicated cookie-echo chunk will create a new asoc with the
      auth info from this chunk, and the authentication should also be
      done with the new asoc's auth info for all of the collision 'A',
      'B' and 'D'. Otherwise, the duplicated cookie-echo chunk with auth
      will never pass the authentication and create the new connection.
      
      This issue exists since very beginning, and this fix is to make
      sctp_assoc_bh_rcv() follow the way sctp_endpoint_bh_rcv() does
      for the normal cookie-echo chunk to delay the authentication.
      
      While at it, remove the unused params from sctp_sf_authenticate()
      and define sctp_auth_chunk_verify() used for all the places that
      do the delayed authentication.
      
      v1->v2:
        fix the typo in changelog as Marcelo noticed.
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59d8d443
    • S
      mac80211: use timeout from the AddBA response instead of the request · 914eac24
      Sara Sharon 提交于
      2016 spec, section 10.24.2 specifies that the block ack
      timeout in the ADD BA request is advisory.
      
      That means we should check the value in the response and
      act upon it (same as buffer size).
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      914eac24
  7. 07 5月, 2018 2 次提交
  8. 05 5月, 2018 4 次提交
    • Y
      net/netlink: make sure the headers line up actual value output · ae552ac2
      YU Bo 提交于
      Making sure the headers line up properly with the actual value output of the command
      `cat /proc/net/netlink`
      
      Before the patch:
      <sk       Eth Pid    Groups   Rmem     Wmem     Dump     Locks     Drops     Inode
      <ffff8cd2c2f7b000 0   909    00000550 0        0        0 2        0        18946
      
      After the patch:
      >sk               Eth Pid        Groups   Rmem     Wmem     Dump  Locks    Drops    Inode
      >0000000033203952 0   897        00000113 0        0        0     2        0        14906
      Signed-off-by: NBo YU <tsu.yubo@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae552ac2
    • E
      nsh: fix infinite loop · af50e4ba
      Eric Dumazet 提交于
      syzbot caught an infinite recursion in nsh_gso_segment().
      
      Problem here is that we need to make sure the NSH header is of
      reasonable length.
      
      BUG: MAX_LOCK_DEPTH too low!
      turning off the locking correctness validator.
      depth: 48  max: 48!
      48 locks held by syz-executor0/10189:
       #0:         (ptrval) (rcu_read_lock_bh){....}, at: __dev_queue_xmit+0x30f/0x34c0 net/core/dev.c:3517
       #1:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #1:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #2:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #2:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #3:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #3:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #4:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #4:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #5:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #5:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #6:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #6:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #7:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #7:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #8:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #8:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #9:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #9:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #10:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #10:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #11:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #11:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #12:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #12:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #13:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #13:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #14:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #14:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #15:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #15:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #16:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #16:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #17:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #17:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #18:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #18:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #19:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #19:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #20:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #20:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #21:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #21:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #22:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #22:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #23:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #23:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #24:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #24:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #25:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #25:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #26:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #26:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #27:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #27:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #28:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #28:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #29:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #29:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #30:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #30:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #31:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #31:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
      dccp_close: ABORT with 65423 bytes unread
       #32:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #32:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #33:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #33:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #34:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #34:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #35:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #35:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #36:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #36:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #37:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #37:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #38:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #38:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #39:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #39:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #40:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #40:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #41:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #41:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #42:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #42:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #43:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #43:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #44:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #44:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #45:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #45:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #46:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #46:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
       #47:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
       #47:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
      INFO: lockdep is turned off.
      CPU: 1 PID: 10189 Comm: syz-executor0 Not tainted 4.17.0-rc2+ #26
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1b9/0x294 lib/dump_stack.c:113
       __lock_acquire+0x1788/0x5140 kernel/locking/lockdep.c:3449
       lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
       rcu_lock_acquire include/linux/rcupdate.h:246 [inline]
       rcu_read_lock include/linux/rcupdate.h:632 [inline]
       skb_mac_gso_segment+0x25b/0x720 net/core/dev.c:2789
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       __skb_gso_segment+0x3bb/0x870 net/core/dev.c:2865
       skb_gso_segment include/linux/netdevice.h:4025 [inline]
       validate_xmit_skb+0x54d/0xd90 net/core/dev.c:3118
       validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3168
       sch_direct_xmit+0x354/0x11e0 net/sched/sch_generic.c:312
       qdisc_restart net/sched/sch_generic.c:399 [inline]
       __qdisc_run+0x741/0x1af0 net/sched/sch_generic.c:410
       __dev_xmit_skb net/core/dev.c:3243 [inline]
       __dev_queue_xmit+0x28ea/0x34c0 net/core/dev.c:3551
       dev_queue_xmit+0x17/0x20 net/core/dev.c:3616
       packet_snd net/packet/af_packet.c:2951 [inline]
       packet_sendmsg+0x40f8/0x6070 net/packet/af_packet.c:2976
       sock_sendmsg_nosec net/socket.c:629 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:639
       __sys_sendto+0x3d7/0x670 net/socket.c:1789
       __do_sys_sendto net/socket.c:1801 [inline]
       __se_sys_sendto net/socket.c:1797 [inline]
       __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
       do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: c411ed85 ("nsh: add GSO support")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Jiri Benc <jbenc@redhat.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af50e4ba
    • G
      net: atm: Fix potential Spectre v1 · acf784bd
      Gustavo A. R. Silva 提交于
      ioc_data.dev_num can be controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      net/atm/lec.c:702 lec_vcc_attach() warn: potential spectre issue
      'dev_lec'
      
      Fix this by sanitizing ioc_data.dev_num before using it to index
      dev_lec. Also, notice that there is another instance in which array
      dev_lec is being indexed using ioc_data.dev_num at line 705:
      lec_vcc_added(netdev_priv(dev_lec[ioc_data.dev_num]),
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acf784bd
    • S
      openvswitch: Don't swap table in nlattr_set() after OVS_ATTR_NESTED is found · 72f17baf
      Stefano Brivio 提交于
      If an OVS_ATTR_NESTED attribute type is found while walking
      through netlink attributes, we call nlattr_set() recursively
      passing the length table for the following nested attributes, if
      different from the current one.
      
      However, once we're done with those sub-nested attributes, we
      should continue walking through attributes using the current
      table, instead of using the one related to the sub-nested
      attributes.
      
      For example, given this sequence:
      
      1  OVS_KEY_ATTR_PRIORITY
      2  OVS_KEY_ATTR_TUNNEL
      3	OVS_TUNNEL_KEY_ATTR_ID
      4	OVS_TUNNEL_KEY_ATTR_IPV4_SRC
      5	OVS_TUNNEL_KEY_ATTR_IPV4_DST
      6	OVS_TUNNEL_KEY_ATTR_TTL
      7	OVS_TUNNEL_KEY_ATTR_TP_SRC
      8	OVS_TUNNEL_KEY_ATTR_TP_DST
      9  OVS_KEY_ATTR_IN_PORT
      10 OVS_KEY_ATTR_SKB_MARK
      11 OVS_KEY_ATTR_MPLS
      
      we switch to the 'ovs_tunnel_key_lens' table on attribute #3,
      and we don't switch back to 'ovs_key_lens' while setting
      attributes #9 to #11 in the sequence. As OVS_KEY_ATTR_MPLS
      evaluates to 21, and the array size of 'ovs_tunnel_key_lens' is
      15, we also get this kind of KASan splat while accessing the
      wrong table:
      
      [ 7654.586496] ==================================================================
      [ 7654.594573] BUG: KASAN: global-out-of-bounds in nlattr_set+0x164/0xde9 [openvswitch]
      [ 7654.603214] Read of size 4 at addr ffffffffc169ecf0 by task handler29/87430
      [ 7654.610983]
      [ 7654.612644] CPU: 21 PID: 87430 Comm: handler29 Kdump: loaded Not tainted 3.10.0-866.el7.test.x86_64 #1
      [ 7654.623030] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.1.7 06/16/2016
      [ 7654.631379] Call Trace:
      [ 7654.634108]  [<ffffffffb65a7c50>] dump_stack+0x19/0x1b
      [ 7654.639843]  [<ffffffffb53ff373>] print_address_description+0x33/0x290
      [ 7654.647129]  [<ffffffffc169b37b>] ? nlattr_set+0x164/0xde9 [openvswitch]
      [ 7654.654607]  [<ffffffffb53ff812>] kasan_report.part.3+0x242/0x330
      [ 7654.661406]  [<ffffffffb53ff9b4>] __asan_report_load4_noabort+0x34/0x40
      [ 7654.668789]  [<ffffffffc169b37b>] nlattr_set+0x164/0xde9 [openvswitch]
      [ 7654.676076]  [<ffffffffc167ef68>] ovs_nla_get_match+0x10c8/0x1900 [openvswitch]
      [ 7654.684234]  [<ffffffffb61e9cc8>] ? genl_rcv+0x28/0x40
      [ 7654.689968]  [<ffffffffb61e7733>] ? netlink_unicast+0x3f3/0x590
      [ 7654.696574]  [<ffffffffc167dea0>] ? ovs_nla_put_tunnel_info+0xb0/0xb0 [openvswitch]
      [ 7654.705122]  [<ffffffffb4f41b50>] ? unwind_get_return_address+0xb0/0xb0
      [ 7654.712503]  [<ffffffffb65d9355>] ? system_call_fastpath+0x1c/0x21
      [ 7654.719401]  [<ffffffffb4f41d79>] ? update_stack_state+0x229/0x370
      [ 7654.726298]  [<ffffffffb4f41d79>] ? update_stack_state+0x229/0x370
      [ 7654.733195]  [<ffffffffb53fe4b5>] ? kasan_unpoison_shadow+0x35/0x50
      [ 7654.740187]  [<ffffffffb53fe62a>] ? kasan_kmalloc+0xaa/0xe0
      [ 7654.746406]  [<ffffffffb53fec32>] ? kasan_slab_alloc+0x12/0x20
      [ 7654.752914]  [<ffffffffb53fe711>] ? memset+0x31/0x40
      [ 7654.758456]  [<ffffffffc165bf92>] ovs_flow_cmd_new+0x2b2/0xf00 [openvswitch]
      
      [snip]
      
      [ 7655.132484] The buggy address belongs to the variable:
      [ 7655.138226]  ovs_tunnel_key_lens+0xf0/0xffffffffffffd400 [openvswitch]
      [ 7655.145507]
      [ 7655.147166] Memory state around the buggy address:
      [ 7655.152514]  ffffffffc169eb80: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
      [ 7655.160585]  ffffffffc169ec00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [ 7655.168644] >ffffffffc169ec80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa
      [ 7655.176701]                                                              ^
      [ 7655.184372]  ffffffffc169ed00: fa fa fa fa 00 00 00 00 fa fa fa fa 00 00 00 05
      [ 7655.192431]  ffffffffc169ed80: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
      [ 7655.200490] ==================================================================
      Reported-by: NHangbin Liu <liuhangbin@gmail.com>
      Fixes: 982b5270 ("openvswitch: Fix mask generation for nested attributes.")
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72f17baf
  9. 04 5月, 2018 4 次提交
    • E
      dccp: fix tasklet usage · a8d7aa17
      Eric Dumazet 提交于
      syzbot reported a crash in tasklet_action_common() caused by dccp.
      
      dccp needs to make sure socket wont disappear before tasklet handler
      has completed.
      
      This patch takes a reference on the socket when arming the tasklet,
      and moves the sock_put() from dccp_write_xmit_timer() to dccp_write_xmitlet()
      
      kernel BUG at kernel/softirq.c:514!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.17.0-rc3+ #30
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:tasklet_action_common.isra.19+0x6db/0x700 kernel/softirq.c:515
      RSP: 0018:ffff8801d9b3faf8 EFLAGS: 00010246
      dccp_close: ABORT with 65423 bytes unread
      RAX: 1ffff1003b367f6b RBX: ffff8801daf1f3f0 RCX: 0000000000000000
      RDX: ffff8801cf895498 RSI: 0000000000000004 RDI: 0000000000000000
      RBP: ffff8801d9b3fc40 R08: ffffed0039f12a95 R09: ffffed0039f12a94
      dccp_close: ABORT with 65423 bytes unread
      R10: ffffed0039f12a94 R11: ffff8801cf8954a3 R12: 0000000000000000
      R13: ffff8801d9b3fc18 R14: dffffc0000000000 R15: ffff8801cf895490
      FS:  0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b2bc28000 CR3: 00000001a08a9000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       tasklet_action+0x1d/0x20 kernel/softirq.c:533
       __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
      dccp_close: ABORT with 65423 bytes unread
       run_ksoftirqd+0x86/0x100 kernel/softirq.c:646
       smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
       kthread+0x345/0x410 kernel/kthread.c:238
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
      Code: 48 8b 85 e8 fe ff ff 48 8b 95 f0 fe ff ff e9 94 fb ff ff 48 89 95 f0 fe ff ff e8 81 53 6e 00 48 8b 95 f0 fe ff ff e9 62 fb ff ff <0f> 0b 48 89 cf 48 89 8d e8 fe ff ff e8 64 53 6e 00 48 8b 8d e8
      RIP: tasklet_action_common.isra.19+0x6db/0x700 kernel/softirq.c:515 RSP: ffff8801d9b3faf8
      
      Fixes: dc841e30 ("dccp: Extend CCID packet dequeueing interface")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
      Cc: dccp@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8d7aa17
    • S
      smc: fix sendpage() call · bda27ff5
      Stefan Raspl 提交于
      The sendpage() call grabs the sock lock before calling the default
      implementation - which tries to grab it once again.
      Signed-off-by: NStefan Raspl <raspl@linux.ibm.com>
      Signed-off-by: Ursula Braun <ubraun@linux.ibm.com><
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bda27ff5
    • K
      net/smc: handle unregistered buffers · a6920d1d
      Karsten Graul 提交于
      When smc_wr_reg_send() fails then tag (regerr) the affected buffer and
      free it in smc_buf_unuse().
      Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a6920d1d
    • K
      net/smc: call consolidation · e63a5f8c
      Karsten Graul 提交于
      Consolidate the call to smc_wr_reg_send() in a new function.
      No functional changes.
      Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e63a5f8c