1. 11 4月, 2018 1 次提交
  2. 10 4月, 2018 1 次提交
  3. 09 4月, 2018 4 次提交
    • E
      inetpeer: fix uninit-value in inet_getpeer · b6a37e5e
      Eric Dumazet 提交于
      syzbot/KMSAN reported that p->dtime was read while it was
      not yet initialized in :
      
      	delta = (__u32)jiffies - p->dtime;
      	if (delta < ttl || !refcount_dec_if_one(&p->refcnt))
      		gc_stack[i] = NULL;
      
      This is a false positive, because the inetpeer wont be erased
      from rb-tree if the refcount_dec_if_one(&p->refcnt) does not
      succeed. And this wont happen before first inet_putpeer() call
      for this inetpeer has been done, and ->dtime field is written
      exactly before the refcount_dec_and_test(&p->refcnt).
      
      The KMSAN report was :
      
      BUG: KMSAN: uninit-value in inet_peer_gc net/ipv4/inetpeer.c:163 [inline]
      BUG: KMSAN: uninit-value in inet_getpeer+0x1567/0x1e70 net/ipv4/inetpeer.c:228
      CPU: 0 PID: 9494 Comm: syz-executor5 Not tainted 4.16.0+ #82
      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:676
       inet_peer_gc net/ipv4/inetpeer.c:163 [inline]
       inet_getpeer+0x1567/0x1e70 net/ipv4/inetpeer.c:228
       inet_getpeer_v4 include/net/inetpeer.h:110 [inline]
       icmpv4_xrlim_allow net/ipv4/icmp.c:330 [inline]
       icmp_send+0x2b44/0x3050 net/ipv4/icmp.c:725
       ip_options_compile+0x237c/0x29f0 net/ipv4/ip_options.c:472
       ip_rcv_options net/ipv4/ip_input.c:284 [inline]
       ip_rcv_finish+0xda8/0x16d0 net/ipv4/ip_input.c:365
       NF_HOOK include/linux/netfilter.h:288 [inline]
       ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
       __netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
       __netif_receive_skb net/core/dev.c:4627 [inline]
       netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
       netif_receive_skb+0x230/0x240 net/core/dev.c:4725
       tun_rx_batched drivers/net/tun.c:1555 [inline]
       tun_get_user+0x6d88/0x7580 drivers/net/tun.c:1962
       tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
       do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
       do_iter_write+0x30d/0xd40 fs/read_write.c:932
       vfs_writev fs/read_write.c:977 [inline]
       do_writev+0x3c9/0x830 fs/read_write.c:1012
       SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
       SyS_writev+0x56/0x80 fs/read_write.c:1082
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x455111
      RSP: 002b:00007fae0365cba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 000000000000002e RCX: 0000000000455111
      RDX: 0000000000000001 RSI: 00007fae0365cbf0 RDI: 00000000000000fc
      RBP: 0000000020000040 R08: 00000000000000fc R09: 0000000000000000
      R10: 000000000000002e R11: 0000000000000293 R12: 00000000ffffffff
      R13: 0000000000000658 R14: 00000000006fc8e0 R15: 0000000000000000
      
      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
       kmem_cache_alloc+0xaab/0xb90 mm/slub.c:2756
       inet_getpeer+0xed8/0x1e70 net/ipv4/inetpeer.c:210
       inet_getpeer_v4 include/net/inetpeer.h:110 [inline]
       ip4_frag_init+0x4d1/0x740 net/ipv4/ip_fragment.c:153
       inet_frag_alloc net/ipv4/inet_fragment.c:369 [inline]
       inet_frag_create net/ipv4/inet_fragment.c:385 [inline]
       inet_frag_find+0x7da/0x1610 net/ipv4/inet_fragment.c:418
       ip_find net/ipv4/ip_fragment.c:275 [inline]
       ip_defrag+0x448/0x67a0 net/ipv4/ip_fragment.c:676
       ip_check_defrag+0x775/0xda0 net/ipv4/ip_fragment.c:724
       packet_rcv_fanout+0x2a8/0x8d0 net/packet/af_packet.c:1447
       deliver_skb net/core/dev.c:1897 [inline]
       deliver_ptype_list_skb net/core/dev.c:1912 [inline]
       __netif_receive_skb_core+0x314a/0x4a80 net/core/dev.c:4545
       __netif_receive_skb net/core/dev.c:4627 [inline]
       netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
       netif_receive_skb+0x230/0x240 net/core/dev.c:4725
       tun_rx_batched drivers/net/tun.c:1555 [inline]
       tun_get_user+0x6d88/0x7580 drivers/net/tun.c:1962
       tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
       do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
       do_iter_write+0x30d/0xd40 fs/read_write.c:932
       vfs_writev fs/read_write.c:977 [inline]
       do_writev+0x3c9/0x830 fs/read_write.c:1012
       SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
       SyS_writev+0x56/0x80 fs/read_write.c:1082
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6a37e5e
    • J
      devlink: convert occ_get op to separate registration · fc56be47
      Jiri Pirko 提交于
      This resolves race during initialization where the resources with
      ops are registered before driver and the structures used by occ_get
      op is initialized. So keep occ_get callbacks registered only when
      all structs are initialized.
      
      The example flows, as it is in mlxsw:
      1) driver load/asic probe:
         mlxsw_core
            -> mlxsw_sp_resources_register
              -> mlxsw_sp_kvdl_resources_register
                -> devlink_resource_register IDX
         mlxsw_spectrum
            -> mlxsw_sp_kvdl_init
              -> mlxsw_sp_kvdl_parts_init
                -> mlxsw_sp_kvdl_part_init
                  -> devlink_resource_size_get IDX (to get the current setup
                                                    size from devlink)
              -> devlink_resource_occ_get_register IDX (register current
                                                        occupancy getter)
      2) reload triggered by devlink command:
        -> mlxsw_devlink_core_bus_device_reload
          -> mlxsw_sp_fini
            -> mlxsw_sp_kvdl_fini
      	-> devlink_resource_occ_get_unregister IDX
          (struct mlxsw_sp *mlxsw_sp is freed at this point, call to occ get
           which is using mlxsw_sp would cause use-after free)
          -> mlxsw_sp_init
            -> mlxsw_sp_kvdl_init
              -> mlxsw_sp_kvdl_parts_init
                -> mlxsw_sp_kvdl_part_init
                  -> devlink_resource_size_get IDX (to get the current setup
                                                    size from devlink)
              -> devlink_resource_occ_get_register IDX (register current
                                                        occupancy getter)
      
      Fixes: d9f9b9a4 ("devlink: Add support for resource abstraction")
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fc56be47
    • C
      tipc: use the right skb in tipc_sk_fill_sock_diag() · e41f0548
      Cong Wang 提交于
      Commit 4b2e6877 ("tipc: Fix namespace violation in tipc_sk_fill_sock_diag")
      tried to fix the crash but failed, the crash is still 100% reproducible
      with it.
      
      In tipc_sk_fill_sock_diag(), skb is the diag dump we are filling, it is not
      correct to retrieve its NETLINK_CB(), instead, like other protocol diag,
      we should use NETLINK_CB(cb->skb).sk here.
      
      Reported-by: <syzbot+326e587eff1074657718@syzkaller.appspotmail.com>
      Fixes: 4b2e6877 ("tipc: Fix namespace violation in tipc_sk_fill_sock_diag")
      Fixes: c30b70de (tipc: implement socket diagnostics for AF_TIPC)
      Cc: GhantaKrishnamurthy MohanKrishna <mohan.krishna.ghanta.krishnamurthy@ericsson.com>
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Cc: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e41f0548
    • E
      sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6 · 81e98370
      Eric Dumazet 提交于
      Check must happen before call to ipv6_addr_v4mapped()
      
      syzbot report was :
      
      BUG: KMSAN: uninit-value in sctp_sockaddr_af net/sctp/socket.c:359 [inline]
      BUG: KMSAN: uninit-value in sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384
      CPU: 0 PID: 3576 Comm: syzkaller968804 Not tainted 4.16.0+ #82
      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:676
       sctp_sockaddr_af net/sctp/socket.c:359 [inline]
       sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384
       sctp_bind+0x149/0x190 net/sctp/socket.c:332
       inet6_bind+0x1fd/0x1820 net/ipv6/af_inet6.c:293
       SYSC_bind+0x3f2/0x4b0 net/socket.c:1474
       SyS_bind+0x54/0x80 net/socket.c:1460
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x43fd49
      RSP: 002b:00007ffe99df3d28 EFLAGS: 00000213 ORIG_RAX: 0000000000000031
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd49
      RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401670
      R13: 0000000000401700 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----address@SYSC_bind
      Variable was created at:
       SYSC_bind+0x6f/0x4b0 net/socket.c:1461
       SyS_bind+0x54/0x80 net/socket.c:1460
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81e98370
  4. 08 4月, 2018 9 次提交
    • A
      net: dsa: Discard frames from unused ports · fc5f3376
      Andrew Lunn 提交于
      The Marvell switches under some conditions will pass a frame to the
      host with the port being the CPU port. Such frames are invalid, and
      should be dropped. Not dropping them can result in a crash when
      incrementing the receive statistics for an invalid port.
      Reported-by: NChris Healy <cphealy@gmail.com>
      Fixes: 91da11f8 ("net: Distributed Switch Architecture protocol support")
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fc5f3376
    • E
      sctp: do not leak kernel memory to user space · 6780db24
      Eric Dumazet 提交于
      syzbot produced a nice report [1]
      
      Issue here is that a recvmmsg() managed to leak 8 bytes of kernel memory
      to user space, because sin_zero (padding field) was not properly cleared.
      
      [1]
      BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184 [inline]
      BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530 net/socket.c:227
      CPU: 1 PID: 3586 Comm: syzkaller481044 Not tainted 4.16.0+ #82
      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
       kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
       kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
       copy_to_user include/linux/uaccess.h:184 [inline]
       move_addr_to_user+0x32e/0x530 net/socket.c:227
       ___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
       SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
       SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x4401c9
      RSP: 002b:00007ffc56f73098 EFLAGS: 00000217 ORIG_RAX: 000000000000012b
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401c9
      RDX: 0000000000000001 RSI: 0000000020003ac0 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 0000000020003bc0 R09: 0000000000000010
      R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000401af0
      R13: 0000000000401b80 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----addr@___sys_recvmsg
      Variable was created at:
       ___sys_recvmsg+0xd5/0x810 net/socket.c:2172
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
      
      Bytes 8-15 of 16 are uninitialized
      
      ==================================================================
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 3586 Comm: syzkaller481044 Tainted: G    B            4.16.0+ #82
      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
       panic+0x39d/0x940 kernel/panic.c:183
       kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
       kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
       kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
       copy_to_user include/linux/uaccess.h:184 [inline]
       move_addr_to_user+0x32e/0x530 net/socket.c:227
       ___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
       SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
       SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc:	Vlad Yasevich <vyasevich@gmail.com>
      Cc:	Neil Horman <nhorman@tuxdriver.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6780db24
    • E
      soreuseport: initialise timewait reuseport field · 3099a529
      Eric Dumazet 提交于
      syzbot reported an uninit-value in inet_csk_bind_conflict() [1]
      
      It turns out we never propagated sk->sk_reuseport into timewait socket.
      
      [1]
      BUG: KMSAN: uninit-value in inet_csk_bind_conflict+0x5f9/0x990 net/ipv4/inet_connection_sock.c:151
      CPU: 1 PID: 3589 Comm: syzkaller008242 Not tainted 4.16.0+ #82
      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:676
       inet_csk_bind_conflict+0x5f9/0x990 net/ipv4/inet_connection_sock.c:151
       inet_csk_get_port+0x1d28/0x1e40 net/ipv4/inet_connection_sock.c:320
       inet6_bind+0x121c/0x1820 net/ipv6/af_inet6.c:399
       SYSC_bind+0x3f2/0x4b0 net/socket.c:1474
       SyS_bind+0x54/0x80 net/socket.c:1460
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x4416e9
      RSP: 002b:00007ffce6d15c88 EFLAGS: 00000217 ORIG_RAX: 0000000000000031
      RAX: ffffffffffffffda RBX: 0100000000000000 RCX: 00000000004416e9
      RDX: 000000000000001c RSI: 0000000020402000 RDI: 0000000000000004
      RBP: 0000000000000000 R08: 00000000e6d15e08 R09: 00000000e6d15e08
      R10: 0000000000000004 R11: 0000000000000217 R12: 0000000000009478
      R13: 00000000006cd448 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
       kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
       __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
       tcp_time_wait+0xf17/0xf50 net/ipv4/tcp_minisocks.c:283
       tcp_rcv_state_process+0xebe/0x6490 net/ipv4/tcp_input.c:6003
       tcp_v6_do_rcv+0x11dd/0x1d90 net/ipv6/tcp_ipv6.c:1331
       sk_backlog_rcv include/net/sock.h:908 [inline]
       __release_sock+0x2d6/0x680 net/core/sock.c:2271
       release_sock+0x97/0x2a0 net/core/sock.c:2786
       tcp_close+0x277/0x18f0 net/ipv4/tcp.c:2269
       inet_release+0x240/0x2a0 net/ipv4/af_inet.c:427
       inet6_release+0xaf/0x100 net/ipv6/af_inet6.c:435
       sock_release net/socket.c:595 [inline]
       sock_close+0xe0/0x300 net/socket.c:1149
       __fput+0x49e/0xa10 fs/file_table.c:209
       ____fput+0x37/0x40 fs/file_table.c:243
       task_work_run+0x243/0x2c0 kernel/task_work.c:113
       exit_task_work include/linux/task_work.h:22 [inline]
       do_exit+0x10e1/0x38d0 kernel/exit.c:867
       do_group_exit+0x1a0/0x360 kernel/exit.c:970
       SYSC_exit_group+0x21/0x30 kernel/exit.c:981
       SyS_exit_group+0x25/0x30 kernel/exit.c:979
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
       kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
       __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
       inet_twsk_alloc+0xaef/0xc00 net/ipv4/inet_timewait_sock.c:182
       tcp_time_wait+0xd9/0xf50 net/ipv4/tcp_minisocks.c:258
       tcp_rcv_state_process+0xebe/0x6490 net/ipv4/tcp_input.c:6003
       tcp_v6_do_rcv+0x11dd/0x1d90 net/ipv6/tcp_ipv6.c:1331
       sk_backlog_rcv include/net/sock.h:908 [inline]
       __release_sock+0x2d6/0x680 net/core/sock.c:2271
       release_sock+0x97/0x2a0 net/core/sock.c:2786
       tcp_close+0x277/0x18f0 net/ipv4/tcp.c:2269
       inet_release+0x240/0x2a0 net/ipv4/af_inet.c:427
       inet6_release+0xaf/0x100 net/ipv6/af_inet6.c:435
       sock_release net/socket.c:595 [inline]
       sock_close+0xe0/0x300 net/socket.c:1149
       __fput+0x49e/0xa10 fs/file_table.c:209
       ____fput+0x37/0x40 fs/file_table.c:243
       task_work_run+0x243/0x2c0 kernel/task_work.c:113
       exit_task_work include/linux/task_work.h:22 [inline]
       do_exit+0x10e1/0x38d0 kernel/exit.c:867
       do_group_exit+0x1a0/0x360 kernel/exit.c:970
       SYSC_exit_group+0x21/0x30 kernel/exit.c:981
       SyS_exit_group+0x25/0x30 kernel/exit.c:979
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      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
       kmem_cache_alloc+0xaab/0xb90 mm/slub.c:2756
       inet_twsk_alloc+0x13b/0xc00 net/ipv4/inet_timewait_sock.c:163
       tcp_time_wait+0xd9/0xf50 net/ipv4/tcp_minisocks.c:258
       tcp_rcv_state_process+0xebe/0x6490 net/ipv4/tcp_input.c:6003
       tcp_v6_do_rcv+0x11dd/0x1d90 net/ipv6/tcp_ipv6.c:1331
       sk_backlog_rcv include/net/sock.h:908 [inline]
       __release_sock+0x2d6/0x680 net/core/sock.c:2271
       release_sock+0x97/0x2a0 net/core/sock.c:2786
       tcp_close+0x277/0x18f0 net/ipv4/tcp.c:2269
       inet_release+0x240/0x2a0 net/ipv4/af_inet.c:427
       inet6_release+0xaf/0x100 net/ipv6/af_inet6.c:435
       sock_release net/socket.c:595 [inline]
       sock_close+0xe0/0x300 net/socket.c:1149
       __fput+0x49e/0xa10 fs/file_table.c:209
       ____fput+0x37/0x40 fs/file_table.c:243
       task_work_run+0x243/0x2c0 kernel/task_work.c:113
       exit_task_work include/linux/task_work.h:22 [inline]
       do_exit+0x10e1/0x38d0 kernel/exit.c:867
       do_group_exit+0x1a0/0x360 kernel/exit.c:970
       SYSC_exit_group+0x21/0x30 kernel/exit.c:981
       SyS_exit_group+0x25/0x30 kernel/exit.c:979
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      Fixes: da5e3630 ("soreuseport: TCP/IPv4 implementation")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3099a529
    • E
      ipv4: fix uninit-value in ip_route_output_key_hash_rcu() · d0ea2b12
      Eric Dumazet 提交于
      syzbot complained that res.type could be used while not initialized.
      
      Using RTN_UNSPEC as initial value seems better than using garbage.
      
      BUG: KMSAN: uninit-value in __mkroute_output net/ipv4/route.c:2200 [inline]
      BUG: KMSAN: uninit-value in ip_route_output_key_hash_rcu+0x31f0/0x3940 net/ipv4/route.c:2493
      CPU: 1 PID: 12207 Comm: syz-executor0 Not tainted 4.16.0+ #81
      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:676
       __mkroute_output net/ipv4/route.c:2200 [inline]
       ip_route_output_key_hash_rcu+0x31f0/0x3940 net/ipv4/route.c:2493
       ip_route_output_key_hash net/ipv4/route.c:2322 [inline]
       __ip_route_output_key include/net/route.h:126 [inline]
       ip_route_output_flow+0x1eb/0x3c0 net/ipv4/route.c:2577
       raw_sendmsg+0x1861/0x3ed0 net/ipv4/raw.c:653
       inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
       sock_sendmsg_nosec net/socket.c:630 [inline]
       sock_sendmsg net/socket.c:640 [inline]
       SYSC_sendto+0x6c3/0x7e0 net/socket.c:1747
       SyS_sendto+0x8a/0xb0 net/socket.c:1715
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x455259
      RSP: 002b:00007fdc0625dc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 00007fdc0625e6d4 RCX: 0000000000455259
      RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000013
      RBP: 000000000072bea0 R08: 0000000020000080 R09: 0000000000000010
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000000004f7 R14: 00000000006fa7c8 R15: 0000000000000000
      
      Local variable description: ----res.i.i@ip_route_output_flow
      Variable was created at:
       ip_route_output_flow+0x75/0x3c0 net/ipv4/route.c:2576
       raw_sendmsg+0x1861/0x3ed0 net/ipv4/raw.c:653
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0ea2b12
    • E
      dccp: initialize ireq->ir_mark · b855ff82
      Eric Dumazet 提交于
      syzbot reported an uninit-value read of skb->mark in iptable_mangle_hook()
      
      Thanks to the nice report, I tracked the problem to dccp not caring
      of ireq->ir_mark for passive sessions.
      
      BUG: KMSAN: uninit-value in ipt_mangle_out net/ipv4/netfilter/iptable_mangle.c:66 [inline]
      BUG: KMSAN: uninit-value in iptable_mangle_hook+0x5e5/0x720 net/ipv4/netfilter/iptable_mangle.c:84
      CPU: 0 PID: 5300 Comm: syz-executor3 Not tainted 4.16.0+ #81
      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:676
       ipt_mangle_out net/ipv4/netfilter/iptable_mangle.c:66 [inline]
       iptable_mangle_hook+0x5e5/0x720 net/ipv4/netfilter/iptable_mangle.c:84
       nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
       nf_hook_slow+0x158/0x3d0 net/netfilter/core.c:483
       nf_hook include/linux/netfilter.h:243 [inline]
       __ip_local_out net/ipv4/ip_output.c:113 [inline]
       ip_local_out net/ipv4/ip_output.c:122 [inline]
       ip_queue_xmit+0x1d21/0x21c0 net/ipv4/ip_output.c:504
       dccp_transmit_skb+0x15eb/0x1900 net/dccp/output.c:142
       dccp_xmit_packet+0x814/0x9e0 net/dccp/output.c:281
       dccp_write_xmit+0x20f/0x480 net/dccp/output.c:363
       dccp_sendmsg+0x12ca/0x12d0 net/dccp/proto.c:818
       inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
       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:0x455259
      RSP: 002b:00007f1a4473dc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f1a4473e6d4 RCX: 0000000000455259
      RDX: 0000000000000000 RSI: 0000000020b76fc8 RDI: 0000000000000015
      RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000000004f0 R14: 00000000006fa720 R15: 0000000000000000
      
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
       kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
       __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
       ip_queue_xmit+0x1e35/0x21c0 net/ipv4/ip_output.c:502
       dccp_transmit_skb+0x15eb/0x1900 net/dccp/output.c:142
       dccp_xmit_packet+0x814/0x9e0 net/dccp/output.c:281
       dccp_write_xmit+0x20f/0x480 net/dccp/output.c:363
       dccp_sendmsg+0x12ca/0x12d0 net/dccp/proto.c:818
       inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
       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
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
       kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
       __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
       inet_csk_clone_lock+0x503/0x580 net/ipv4/inet_connection_sock.c:797
       dccp_create_openreq_child+0x7f/0x890 net/dccp/minisocks.c:92
       dccp_v4_request_recv_sock+0x22c/0xe90 net/dccp/ipv4.c:408
       dccp_v6_request_recv_sock+0x290/0x2000 net/dccp/ipv6.c:414
       dccp_check_req+0x7b9/0x8f0 net/dccp/minisocks.c:197
       dccp_v4_rcv+0x12e4/0x2630 net/dccp/ipv4.c:840
       ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
       NF_HOOK include/linux/netfilter.h:288 [inline]
       ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
       dst_input include/net/dst.h:449 [inline]
       ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
       NF_HOOK include/linux/netfilter.h:288 [inline]
       ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
       __netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
       __netif_receive_skb net/core/dev.c:4627 [inline]
       process_backlog+0x62d/0xe20 net/core/dev.c:5307
       napi_poll net/core/dev.c:5705 [inline]
       net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
       __do_softirq+0x56d/0x93d kernel/softirq.c:285
      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
       kmem_cache_alloc+0xaab/0xb90 mm/slub.c:2756
       reqsk_alloc include/net/request_sock.h:88 [inline]
       inet_reqsk_alloc+0xc4/0x7f0 net/ipv4/tcp_input.c:6145
       dccp_v4_conn_request+0x5cc/0x1770 net/dccp/ipv4.c:600
       dccp_v6_conn_request+0x299/0x1880 net/dccp/ipv6.c:317
       dccp_rcv_state_process+0x2ea/0x2410 net/dccp/input.c:612
       dccp_v4_do_rcv+0x229/0x340 net/dccp/ipv4.c:682
       dccp_v6_do_rcv+0x16d/0x1220 net/dccp/ipv6.c:578
       sk_backlog_rcv include/net/sock.h:908 [inline]
       __sk_receive_skb+0x60e/0xf20 net/core/sock.c:513
       dccp_v4_rcv+0x24d4/0x2630 net/dccp/ipv4.c:874
       ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
       NF_HOOK include/linux/netfilter.h:288 [inline]
       ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
       dst_input include/net/dst.h:449 [inline]
       ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
       NF_HOOK include/linux/netfilter.h:288 [inline]
       ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
       __netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
       __netif_receive_skb net/core/dev.c:4627 [inline]
       process_backlog+0x62d/0xe20 net/core/dev.c:5307
       napi_poll net/core/dev.c:5705 [inline]
       net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
       __do_softirq+0x56d/0x93d kernel/softirq.c:285
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b855ff82
    • E
      net: fix uninit-value in __hw_addr_add_ex() · 77d36398
      Eric Dumazet 提交于
      syzbot complained :
      
      BUG: KMSAN: uninit-value in memcmp+0x119/0x180 lib/string.c:861
      CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.16.0+ #82
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: ipv6_addrconf addrconf_dad_work
      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:676
       memcmp+0x119/0x180 lib/string.c:861
       __hw_addr_add_ex net/core/dev_addr_lists.c:60 [inline]
       __dev_mc_add+0x1c2/0x8e0 net/core/dev_addr_lists.c:670
       dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
       igmp6_group_added+0x2db/0xa00 net/ipv6/mcast.c:662
       ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
       addrconf_join_solict net/ipv6/addrconf.c:2078 [inline]
       addrconf_dad_begin net/ipv6/addrconf.c:3828 [inline]
       addrconf_dad_work+0x427/0x2150 net/ipv6/addrconf.c:3954
       process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
       worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
       kthread+0x539/0x720 kernel/kthread.c:239
      
      Fixes: f001fde5 ("net: introduce a list of device addresses dev_addr_list (v6)")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77d36398
    • E
      net: initialize skb->peeked when cloning · b13dda9f
      Eric Dumazet 提交于
      syzbot reported __skb_try_recv_from_queue() was using skb->peeked
      while it was potentially unitialized.
      
      We need to clear it in __skb_clone()
      
      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>
      b13dda9f
    • E
      netlink: fix uninit-value in netlink_sendmsg · 6091f09c
      Eric Dumazet 提交于
      syzbot reported :
      
      BUG: KMSAN: uninit-value in ffs arch/x86/include/asm/bitops.h:432 [inline]
      BUG: KMSAN: uninit-value in netlink_sendmsg+0xb26/0x1310 net/netlink/af_netlink.c:1851
      
      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>
      6091f09c
    • C
      net_sched: fix a missing idr_remove() in u32_delete_key() · f12c6432
      Cong Wang 提交于
      When we delete a u32 key via u32_delete_key(), we forget to
      call idr_remove() to remove its handle from IDR.
      
      Fixes: e7614370 ("net_sched: use idr to allocate u32 filter handles")
      Reported-by: NMarcin Kabiesz <admin@hostcenter.eu>
      Tested-by: NMarcin Kabiesz <admin@hostcenter.eu>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f12c6432
  5. 06 4月, 2018 12 次提交
    • R
      headers: untangle kmemleak.h from mm.h · 514c6032
      Randy Dunlap 提交于
      Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious
      reason.  It looks like it's only a convenience, so remove kmemleak.h
      from slab.h and add <linux/kmemleak.h> to any users of kmemleak_* that
      don't already #include it.  Also remove <linux/kmemleak.h> from source
      files that do not use it.
      
      This is tested on i386 allmodconfig and x86_64 allmodconfig.  It would
      be good to run it through the 0day bot for other $ARCHes.  I have
      neither the horsepower nor the storage space for the other $ARCHes.
      
      Update: This patch has been extensively build-tested by both the 0day
      bot & kisskb/ozlabs build farms.  Both of them reported 2 build failures
      for which patches are included here (in v2).
      
      [ slab.h is the second most used header file after module.h; kernel.h is
        right there with slab.h. There could be some minor error in the
        counting due to some #includes having comments after them and I didn't
        combine all of those. ]
      
      [akpm@linux-foundation.org: security/keys/big_key.c needs vmalloc.h, per sfr]
      Link: http://lkml.kernel.org/r/e4309f98-3749-93e1-4bb7-d9501a39d015@infradead.org
      Link: http://kisskb.ellerman.id.au/kisskb/head/13396/Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Reported-by: Michael Ellerman <mpe@ellerman.id.au>	[2 build failures]
      Reported-by: Fengguang Wu <fengguang.wu@intel.com>	[2 build failures]
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Wei Yongjun <weiyongjun1@huawei.com>
      Cc: Luis R. Rodriguez <mcgrof@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: John Johansen <john.johansen@canonical.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      514c6032
    • C
      net/9p/client.c: fix potential refcnt problem of trans module · 9421c3e6
      Chengguang Xu 提交于
      When specifying trans_mod multiple times in a mount, it will cause an
      inaccurate refcount of the trans module.  Also, in the error case of
      option parsing, we should put the trans module if we have already got
      it.
      
      Link: http://lkml.kernel.org/r/1522154942-57339-1-git-send-email-cgxu519@gmx.comSigned-off-by: NChengguang Xu <cgxu519@gmx.com>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Ron Minnich <rminnich@sandia.gov>
      Cc: Latchesar Ionkov <lucho@ionkov.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9421c3e6
    • G
      net/9p: avoid -ERESTARTSYS leak to userspace · a8522243
      Greg Kurz 提交于
      If it was interrupted by a signal, the 9p client may need to send some
      more requests to the server for cleanup before returning to userspace.
      
      To avoid such a last minute request to be interrupted right away, the
      client memorizes if a signal is pending, clears TIF_SIGPENDING, handles
      the request and calls recalc_sigpending() before returning.
      
      Unfortunately, if the transmission of this cleanup request fails for any
      reason, the transport returns an error and the client propagates it
      right away, without calling recalc_sigpending().
      
      This ends up with -ERESTARTSYS from the initially interrupted request
      crawling up to syscall exit, with TIF_SIGPENDING cleared by the cleanup
      request.  The specific signal handling code, which is responsible for
      converting -ERESTARTSYS to -EINTR is not called, and userspace receives
      the confusing errno value:
      
        open: Unknown error 512 (512)
      
      This is really hard to hit in real life.  I discovered the issue while
      working on hot-unplug of a virtio-9p-pci device with an instrumented
      QEMU allowing to control request completion.
      
      Both p9_client_zc_rpc() and p9_client_rpc() functions have this buggy
      error path actually.  Their code flow is a bit obscure and the best
      thing to do would probably be a full rewrite: to really ensure this
      situation of clearing TIF_SIGPENDING and returning -ERESTARTSYS can
      never happen.
      
      But given the general lack of interest for the 9p code, I won't risk
      breaking more things.  So this patch simply fixes the buggy paths in
      both functions with a trivial label+goto.
      
      Thanks to Laurent Dufour for his help and suggestions on how to find the
      root cause and how to fix it.
      
      Link: http://lkml.kernel.org/r/152062809886.10599.7361006774123053312.stgit@bahia.lanSigned-off-by: NGreg Kurz <groug@kaod.org>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: NYiwen Jiang <jiangyiwen@huawei.com>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Ron Minnich <rminnich@sandia.gov>
      Cc: Latchesar Ionkov <lucho@ionkov.net>
      Cc: David Miller <davem@davemloft.net>
      Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a8522243
    • D
      net/sched: fix NULL dereference in the error path of tcf_bpf_init() · 3239534a
      Davide Caratti 提交于
      when tcf_bpf_init_from_ops() fails (e.g. because of program having invalid
      number of instructions), tcf_bpf_cfg_cleanup() calls bpf_prog_put(NULL) or
      bpf_prog_destroy(NULL). Unless CONFIG_BPF_SYSCALL is unset, this causes
      the following error:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
       PGD 800000007345a067 P4D 800000007345a067 PUD 340e1067 PMD 0
       Oops: 0000 [#1] SMP PTI
       Modules linked in: act_bpf(E) ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 mbcache jbd2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic pcbc snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd glue_helper cryptd joydev snd_timer snd virtio_balloon pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm virtio_blk drm virtio_net virtio_console i2c_core crc32c_intel serio_raw virtio_pci ata_piix libata virtio_ring floppy virtio dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_bpf]
       CPU: 3 PID: 5654 Comm: tc Tainted: G            E    4.16.0.bpf_test+ #408
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:__bpf_prog_put+0xc/0xc0
       RSP: 0018:ffff9594003ef728 EFLAGS: 00010202
       RAX: 0000000000000000 RBX: ffff9594003ef758 RCX: 0000000000000024
       RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
       RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044
       R10: 0000000000000220 R11: ffff8a7ab9f17131 R12: 0000000000000000
       R13: ffff8a7ab7c3c8e0 R14: 0000000000000001 R15: ffff8a7ab88f1054
       FS:  00007fcb2f17c740(0000) GS:ffff8a7abfd80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000020 CR3: 000000007c888006 CR4: 00000000001606e0
       Call Trace:
        tcf_bpf_cfg_cleanup+0x2f/0x40 [act_bpf]
        tcf_bpf_cleanup+0x4c/0x70 [act_bpf]
        __tcf_idr_release+0x79/0x140
        tcf_bpf_init+0x125/0x330 [act_bpf]
        tcf_action_init_1+0x2cc/0x430
        ? get_page_from_freelist+0x3f0/0x11b0
        tcf_action_init+0xd3/0x1b0
        tc_ctl_action+0x18b/0x240
        rtnetlink_rcv_msg+0x29c/0x310
        ? _cond_resched+0x15/0x30
        ? __kmalloc_node_track_caller+0x1b9/0x270
        ? rtnl_calcit.isra.29+0x100/0x100
        netlink_rcv_skb+0xd2/0x110
        netlink_unicast+0x17c/0x230
        netlink_sendmsg+0x2cd/0x3c0
        sock_sendmsg+0x30/0x40
        ___sys_sendmsg+0x27a/0x290
        ? mem_cgroup_commit_charge+0x80/0x130
        ? page_add_new_anon_rmap+0x73/0xc0
        ? do_anonymous_page+0x2a2/0x560
        ? __handle_mm_fault+0xc75/0xe20
        __sys_sendmsg+0x58/0xa0
        do_syscall_64+0x6e/0x1a0
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
       RIP: 0033:0x7fcb2e58eba0
       RSP: 002b:00007ffc93c496c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
       RAX: ffffffffffffffda RBX: 00007ffc93c497f0 RCX: 00007fcb2e58eba0
       RDX: 0000000000000000 RSI: 00007ffc93c49740 RDI: 0000000000000003
       RBP: 000000005ac6a646 R08: 0000000000000002 R09: 0000000000000000
       R10: 00007ffc93c49120 R11: 0000000000000246 R12: 0000000000000000
       R13: 00007ffc93c49804 R14: 0000000000000001 R15: 000000000066afa0
       Code: 5f 00 48 8b 43 20 48 c7 c7 70 2f 7c b8 c7 40 10 00 00 00 00 5b e9 a5 8b 61 00 0f 1f 44 00 00 0f 1f 44 00 00 41 54 55 48 89 fd 53 <48> 8b 47 20 f0 ff 08 74 05 5b 5d 41 5c c3 41 89 f4 0f 1f 44 00
       RIP: __bpf_prog_put+0xc/0xc0 RSP: ffff9594003ef728
       CR2: 0000000000000020
      
      Fix it in tcf_bpf_cfg_cleanup(), ensuring that bpf_prog_{put,destroy}(f)
      is called only when f is not NULL.
      
      Fixes: bbc09e78 ("net/sched: fix idr leak on the error path of tcf_bpf_init()")
      Reported-by: NLucas Bates <lucasb@mojatatu.com>
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3239534a
    • J
      net/ipv6: Increment OUTxxx counters after netfilter hook · 71a1c915
      Jeff Barnhill 提交于
      At the end of ip6_forward(), IPSTATS_MIB_OUTFORWDATAGRAMS and
      IPSTATS_MIB_OUTOCTETS are incremented immediately before the NF_HOOK call
      for NFPROTO_IPV6 / NF_INET_FORWARD.  As a result, these counters get
      incremented regardless of whether or not the netfilter hook allows the
      packet to continue being processed.  This change increments the counters
      in ip6_forward_finish() so that it will not happen if the netfilter hook
      chooses to terminate the packet, which is similar to how IPv4 works.
      Signed-off-by: NJeff Barnhill <0xeffeff@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71a1c915
    • M
      arp: fix arp_filter on l3slave devices · 58b35f27
      Miguel Fadon Perlines 提交于
      arp_filter performs an ip_route_output search for arp source address and
      checks if output device is the same where the arp request was received,
      if it is not, the arp request is not answered.
      
      This route lookup is always done on main route table so l3slave devices
      never find the proper route and arp is not answered.
      
      Passing l3mdev_master_ifindex_rcu(dev) return value as oif fixes the
      lookup for l3slave devices while maintaining same behavior for non
      l3slave devices as this function returns 0 in that case.
      
      Fixes: 613d09b3 ("net: Use VRF device index for lookups on TX")
      Signed-off-by: NMiguel Fadon Perlines <mfadon@teldat.com>
      Acked-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58b35f27
    • E
      vti6: better validate user provided tunnel names · 537b361f
      Eric Dumazet 提交于
      Use valid_name() to make sure user does not provide illegal
      device name.
      
      Fixes: ed1efb2a ("ipv6: Add support for IPsec virtual tunnel interfaces")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      537b361f
    • E
      ip6_tunnel: better validate user provided tunnel names · db7a65e3
      Eric Dumazet 提交于
      Use valid_name() to make sure user does not provide illegal
      device name.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db7a65e3
    • E
      ip6_gre: better validate user provided tunnel names · 5f42df01
      Eric Dumazet 提交于
      Use dev_valid_name() to make sure user does not provide illegal
      device name.
      
      syzbot caught the following bug :
      
      BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
      BUG: KASAN: stack-out-of-bounds in ip6gre_tunnel_locate+0x334/0x860 net/ipv6/ip6_gre.c:339
      Write of size 20 at addr ffff8801afb9f7b8 by task syzkaller851048/4466
      
      CPU: 1 PID: 4466 Comm: syzkaller851048 Not tainted 4.16.0+ #1
      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+0x1b9/0x29f lib/dump_stack.c:53
       print_address_description+0x6c/0x20b mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
       memcpy+0x37/0x50 mm/kasan/kasan.c:303
       strlcpy include/linux/string.h:300 [inline]
       ip6gre_tunnel_locate+0x334/0x860 net/ipv6/ip6_gre.c:339
       ip6gre_tunnel_ioctl+0x69d/0x12e0 net/ipv6/ip6_gre.c:1195
       dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
       dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
       sock_ioctl+0x47e/0x680 net/socket.c:1015
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:500 [inline]
       do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
       ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
       SYSC_ioctl fs/ioctl.c:708 [inline]
       SyS_ioctl+0x24/0x30 fs/ioctl.c:706
       do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      Fixes: c12b395a ("gre: Support GRE over IPv6")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f42df01
    • E
      ipv6: sit: better validate user provided tunnel names · b95211e0
      Eric Dumazet 提交于
      Use dev_valid_name() to make sure user does not provide illegal
      device name.
      
      syzbot caught the following bug :
      
      BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
      BUG: KASAN: stack-out-of-bounds in ipip6_tunnel_locate+0x63b/0xaa0 net/ipv6/sit.c:254
      Write of size 33 at addr ffff8801b64076d8 by task syzkaller932654/4453
      
      CPU: 0 PID: 4453 Comm: syzkaller932654 Not tainted 4.16.0+ #1
      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+0x1b9/0x29f lib/dump_stack.c:53
       print_address_description+0x6c/0x20b mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
       memcpy+0x37/0x50 mm/kasan/kasan.c:303
       strlcpy include/linux/string.h:300 [inline]
       ipip6_tunnel_locate+0x63b/0xaa0 net/ipv6/sit.c:254
       ipip6_tunnel_ioctl+0xe71/0x241b net/ipv6/sit.c:1221
       dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
       dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
       sock_ioctl+0x47e/0x680 net/socket.c:1015
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:500 [inline]
       do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
       ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
       SYSC_ioctl fs/ioctl.c:708 [inline]
       SyS_ioctl+0x24/0x30 fs/ioctl.c:706
       do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      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>
      b95211e0
    • E
      ip_tunnel: better validate user provided tunnel names · 9cb726a2
      Eric Dumazet 提交于
      Use dev_valid_name() to make sure user does not provide illegal
      device name.
      
      syzbot caught the following bug :
      
      BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
      BUG: KASAN: stack-out-of-bounds in __ip_tunnel_create+0xca/0x6b0 net/ipv4/ip_tunnel.c:257
      Write of size 20 at addr ffff8801ac79f810 by task syzkaller268107/4482
      
      CPU: 0 PID: 4482 Comm: syzkaller268107 Not tainted 4.16.0+ #1
      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+0x1b9/0x29f lib/dump_stack.c:53
       print_address_description+0x6c/0x20b mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
       memcpy+0x37/0x50 mm/kasan/kasan.c:303
       strlcpy include/linux/string.h:300 [inline]
       __ip_tunnel_create+0xca/0x6b0 net/ipv4/ip_tunnel.c:257
       ip_tunnel_create net/ipv4/ip_tunnel.c:352 [inline]
       ip_tunnel_ioctl+0x818/0xd40 net/ipv4/ip_tunnel.c:861
       ipip_tunnel_ioctl+0x1c5/0x420 net/ipv4/ipip.c:350
       dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
       dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
       sock_ioctl+0x47e/0x680 net/socket.c:1015
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:500 [inline]
       do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
       ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
       SYSC_ioctl fs/ioctl.c:708 [inline]
       SyS_ioctl+0x24/0x30 fs/ioctl.c:706
       do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      Fixes: c5441932 ("GRE: Refactor GRE tunneling code.")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9cb726a2
    • E
      net: fool proof dev_valid_name() · a9d48205
      Eric Dumazet 提交于
      We want to use dev_valid_name() to validate tunnel names,
      so better use strnlen(name, IFNAMSIZ) than strlen(name) to make
      sure to not upset KASAN.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a9d48205
  6. 05 4月, 2018 1 次提交
  7. 04 4月, 2018 12 次提交
    • G
      tipc: Fix namespace violation in tipc_sk_fill_sock_diag · 4b2e6877
      GhantaKrishnamurthy MohanKrishna 提交于
      To fetch UID info for socket diagnostics, we determine the
      namespace of user context using tipc socket instance. This
      may cause namespace violation, as the kernel will remap based
      on UID.
      
      We fix this by fetching namespace info using the calling userspace
      netlink socket.
      
      Fixes: c30b70de (tipc: implement socket diagnostics for AF_TIPC)
      Reported-by: syzbot+326e587eff1074657718@syzkaller.appspotmail.com
      Acked-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NGhantaKrishnamurthy MohanKrishna <mohan.krishna.ghanta.krishnamurthy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b2e6877
    • P
      net: avoid unneeded atomic operation in ip*_append_data() · 9e8445a5
      Paolo Abeni 提交于
      After commit 694aba69 ("ipv4: factorize sk_wmem_alloc updates
      done by __ip_append_data()") and commit 1f4c6eb2 ("ipv6:
      factorize sk_wmem_alloc updates done by __ip6_append_data()"),
      when transmitting sub MTU datagram, an addtional, unneeded atomic
      operation is performed in ip*_append_data() to update wmem_alloc:
      in the above condition the delta is 0.
      
      The above cause small but measurable performance regression in UDP
      xmit tput test with packet size below MTU.
      
      This change avoids such overhead updating wmem_alloc only if
      wmem_alloc_delta is non zero.
      
      The error path is left intentionally unmodified: it's a slow path
      and simplicity is preferred to performances.
      
      Fixes: 694aba69 ("ipv4: factorize sk_wmem_alloc updates done by __ip_append_data()")
      Fixes: 1f4c6eb2 ("ipv6: factorize sk_wmem_alloc updates done by __ip6_append_data()")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e8445a5
    • J
      tipc: Fix missing list initializations in struct tipc_subscription · b714295a
      Jon Maloy 提交于
      When an item of struct tipc_subscription is created, we fail to
      initialize the two lists aggregated into the struct. This has so far
      never been a problem, since the items are just added to a root
      object by list_add(), which does not require the addee list to be
      pre-initialized. However, syzbot is provoking situations where this
      addition fails, whereupon the attempted removal if the item from
      the list causes a crash.
      
      This problem seems to always have been around, despite that the code
      for creating this object was rewritten in commit 242e82cc ("tipc:
      collapse subscription creation functions"), which is still in net-next.
      
      We fix this for that commit by initializing the two lists properly.
      
      Fixes: 242e82cc ("tipc: collapse subscription creation functions")
      Reported-by: syzbot+0bb443b74ce09197e970@syzkaller.appspotmail.com
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b714295a
    • A
      ipv6: udp: set dst cache for a connected sk if current not valid · 4f858c56
      Alexey Kodanev 提交于
      A new RTF_CACHE route can be created between ip6_sk_dst_lookup_flow()
      and ip6_dst_store() calls in udpv6_sendmsg(), when datagram sending
      results to ICMPV6_PKT_TOOBIG error:
      
          udp_v6_send_skb(), for example with vti6 tunnel:
              vti6_xmit(), get ICMPV6_PKT_TOOBIG error
                  skb_dst_update_pmtu(), can create a RTF_CACHE clone
                  icmpv6_send()
          ...
          udpv6_err()
              ip6_sk_update_pmtu()
                 ip6_update_pmtu(), can create a RTF_CACHE clone
                 ...
                 ip6_datagram_dst_update()
                      ip6_dst_store()
      
      And after commit 33c162a9 ("ipv6: datagram: Update dst cache of
      a connected datagram sk during pmtu update"), the UDPv6 error handler
      can update socket's dst cache, but it can happen before the update in
      the end of udpv6_sendmsg(), preventing getting the new dst cache on
      the next udpv6_sendmsg() calls.
      
      In order to fix it, save dst in a connected socket only if the current
      socket's dst cache is invalid.
      
      The previous patch prepared ip6_sk_dst_lookup_flow() to do that with
      the new argument, and this patch enables it in udpv6_sendmsg().
      
      Fixes: 33c162a9 ("ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update")
      Fixes: 45e4fd26 ("ipv6: Only create RTF_CACHE routes after encountering pmtu exception")
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f858c56
    • A
      ipv6: udp: convert 'connected' to bool type in udpv6_sendmsg() · 9f542f61
      Alexey Kodanev 提交于
      This should make it consistent with ip6_sk_dst_lookup_flow()
      that is accepting the new 'connected' parameter of type bool.
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9f542f61
    • A
      ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow() · 96818159
      Alexey Kodanev 提交于
      Add 'connected' parameter to ip6_sk_dst_lookup_flow() and update
      the cache only if ip6_sk_dst_check() returns NULL and a socket
      is connected.
      
      The function is used as before, the new behavior for UDP sockets
      in udpv6_sendmsg() will be enabled in the next patch.
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96818159
    • A
      ipv6: add a wrapper for ip6_dst_store() with flowi6 checks · 7d6850f7
      Alexey Kodanev 提交于
      Move commonly used pattern of ip6_dst_store() usage to a separate
      function - ip6_sk_dst_store_flow(), which will check the addresses
      for equality using the flow information, before saving them.
      
      There is no functional changes in this patch. In addition, it will
      be used in the next patch, in ip6_sk_dst_lookup_flow().
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d6850f7
    • C
      af_unix: remove redundant lockdep class · 3848ec5d
      Cong Wang 提交于
      After commit 581319c5 ("net/socket: use per af lockdep classes for sk queues")
      sock queue locks now have per-af lockdep classes, including unix socket.
      It is no longer necessary to workaround it.
      
      I noticed this while looking at a syzbot deadlock report, this patch
      itself doesn't fix it (this is why I don't add Reported-by).
      
      Fixes: 581319c5 ("net/socket: use per af lockdep classes for sk queues")
      Cc: Paolo Abeni <pabeni@redhat.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3848ec5d
    • D
      rxrpc: Fix undefined packet handling · b41d7cfe
      David Howells 提交于
      By analogy with other Rx implementations, RxRPC packet types 9, 10 and 11
      should just be discarded rather than being aborted like other undefined
      packet types.
      Reported-by: NJeffrey Altman <jaltman@auristor.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b41d7cfe
    • E
      sunrpc: remove incorrect HMAC request initialization · f3aefb6a
      Eric Biggers 提交于
      make_checksum_hmac_md5() is allocating an HMAC transform and doing
      crypto API calls in the following order:
      
          crypto_ahash_init()
          crypto_ahash_setkey()
          crypto_ahash_digest()
      
      This is wrong because it makes no sense to init() the request before a
      key has been set, given that the initial state depends on the key.  And
      digest() is short for init() + update() + final(), so in this case
      there's no need to explicitly call init() at all.
      
      Before commit 9fa68f62 ("crypto: hash - prevent using keyed hashes
      without setting key") the extra init() had no real effect, at least for
      the software HMAC implementation.  (There are also hardware drivers that
      implement HMAC-MD5, and it's not immediately obvious how gracefully they
      handle init() before setkey().)  But now the crypto API detects this
      incorrect initialization and returns -ENOKEY.  This is breaking NFS
      mounts in some cases.
      
      Fix it by removing the incorrect call to crypto_ahash_init().
      Reported-by: NMichael Young <m.a.young@durham.ac.uk>
      Fixes: 9fa68f62 ("crypto: hash - prevent using keyed hashes without setting key")
      Fixes: fffdaef2 ("gss_krb5: Add support for rc4-hmac encryption")
      Cc: stable@vger.kernel.org
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f3aefb6a
    • C
      NFSD: Clean up legacy NFS SYMLINK argument XDR decoders · 38a70315
      Chuck Lever 提交于
      Move common code in NFSD's legacy SYMLINK decoders into a helper.
      The immediate benefits include:
      
       - one fewer data copies on transports that support DDP
       - consistent error checking across all versions
       - reduction of code duplication
       - support for both legal forms of SYMLINK requests on RDMA
         transports for all versions of NFS (in particular, NFSv2, for
         completeness)
      
      In the long term, this helper is an appropriate spot to perform a
      per-transport call-out to fill the pathname argument using, say,
      RDMA Reads.
      
      Filling the pathname in the proc function also means that eventually
      the incoming filehandle can be interpreted so that filesystem-
      specific memory can be allocated as a sink for the pathname
      argument, rather than using anonymous pages.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      38a70315
    • C
      NFSD: Clean up legacy NFS WRITE argument XDR decoders · 8154ef27
      Chuck Lever 提交于
      Move common code in NFSD's legacy NFS WRITE decoders into a helper.
      The immediate benefit is reduction of code duplication and some nice
      micro-optimizations (see below).
      
      In the long term, this helper can perform a per-transport call-out
      to fill the rq_vec (say, using RDMA Reads).
      
      The legacy WRITE decoders and procs are changed to work like NFSv4,
      which constructs the rq_vec just before it is about to call
      vfs_writev.
      
      Why? Calling a transport call-out from the proc instead of the XDR
      decoder means that the incoming FH can be resolved to a particular
      filesystem and file. This would allow pages from the backing file to
      be presented to the transport to be filled, rather than presenting
      anonymous pages and copying or flipping them into the file's page
      cache later.
      
      I also prefer using the pages in rq_arg.pages, instead of pulling
      the data pages directly out of the rqstp::rq_pages array. This is
      currently the way the NFSv3 write decoder works, but the other two
      do not seem to take this approach. Fixing this removes the only
      reference to rq_pages found in NFSD, eliminating an NFSD assumption
      about how transports use the pages in rq_pages.
      
      Lastly, avoid setting up the first element of rq_vec as a zero-
      length buffer. This happens with an RDMA transport when a normal
      Read chunk is present because the data payload is in rq_arg's
      page list (none of it is in the head buffer).
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      8154ef27