1. 17 Dec, 2018 5 commits
    • Xin Long's avatar
      ipvs: call ip_vs_dst_notifier earlier than ipv6_dev_notf · 3d7eec16
      Xin Long authored
      [ Upstream commit 2a31e4bd9ad255ee40809b5c798c4b1c2b09703b ]
      
      ip_vs_dst_event is supposed to clean up all dst used in ipvs'
      destinations when a net dev is going down. But it works only
      when the dst's dev is the same as the dev from the event.
      
      Now with the same priority but late registration,
      ip_vs_dst_notifier is always called later than ipv6_dev_notf
      where the dst's dev is set to lo for NETDEV_DOWN event.
      
      As the dst's dev lo is not the same as the dev from the event
      in ip_vs_dst_event, ip_vs_dst_notifier doesn't actually work.
      Also as these dst have to wait for dest_trash_timer to clean
      them up. It would cause some non-permanent kernel warnings:
      
        unregister_netdevice: waiting for br0 to become free. Usage count = 3
      
      To fix it, call ip_vs_dst_notifier earlier than ipv6_dev_notf
      by increasing its priority to ADDRCONF_NOTIFY_PRIORITY + 5.
      
      Note that for ipv4 route fib_netdev_notifier doesn't set dst's
      dev to lo in NETDEV_DOWN event, so this fix is only needed when
      IP_VS_IPV6 is defined.
      
      Fixes: 7a4f0761 ("IPVS: init and cleanup restructuring")
      Reported-by: 's avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: 's avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: 's avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      3d7eec16
    • Yuchung Cheng's avatar
      tcp: fix NULL ref in tail loss probe · bd3fa7e1
      Yuchung Cheng authored
      [ Upstream commit b2b7af861122a0c0f6260155c29a1b2e594cd5b5 ]
      
      TCP loss probe timer may fire when the retranmission queue is empty but
      has a non-zero tp->packets_out counter. tcp_send_loss_probe will call
      tcp_rearm_rto which triggers NULL pointer reference by fetching the
      retranmission queue head in its sub-routines.
      
      Add a more detailed warning to help catch the root cause of the inflight
      accounting inconsistency.
      Reported-by: 's avatarRafael Tinoco <rafael.tinoco@linaro.org>
      Signed-off-by: 's avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: 's avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd3fa7e1
    • Eric Dumazet's avatar
      rtnetlink: ndo_dflt_fdb_dump() only work for ARPHRD_ETHER devices · fe25279d
      Eric Dumazet authored
      [ Upstream commit 688838934c231bb08f46db687e57f6d8bf82709c ]
      
      kmsan was able to trigger a kernel-infoleak using a gre device [1]
      
      nlmsg_populate_fdb_fill() has a hard coded assumption
      that dev->addr_len is ETH_ALEN, as normally guaranteed
      for ARPHRD_ETHER devices.
      
      A similar issue was fixed recently in commit da71577545a5
      ("rtnetlink: Disallow FDB configuration for non-Ethernet device")
      
      [1]
      BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:143 [inline]
      BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576
      CPU: 0 PID: 6697 Comm: syz-executor310 Not tainted 4.20.0-rc3+ #95
      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+0x32d/0x480 lib/dump_stack.c:113
       kmsan_report+0x12c/0x290 mm/kmsan/kmsan.c:683
       kmsan_internal_check_memory+0x32a/0xa50 mm/kmsan/kmsan.c:743
       kmsan_copy_to_user+0x78/0xd0 mm/kmsan/kmsan_hooks.c:634
       copyout lib/iov_iter.c:143 [inline]
       _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576
       copy_to_iter include/linux/uio.h:143 [inline]
       skb_copy_datagram_iter+0x4e2/0x1070 net/core/datagram.c:431
       skb_copy_datagram_msg include/linux/skbuff.h:3316 [inline]
       netlink_recvmsg+0x6f9/0x19d0 net/netlink/af_netlink.c:1975
       sock_recvmsg_nosec net/socket.c:794 [inline]
       sock_recvmsg+0x1d1/0x230 net/socket.c:801
       ___sys_recvmsg+0x444/0xae0 net/socket.c:2278
       __sys_recvmsg net/socket.c:2327 [inline]
       __do_sys_recvmsg net/socket.c:2337 [inline]
       __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
       __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x441119
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fffc7f008a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002f
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441119
      RDX: 0000000000000040 RSI: 00000000200005c0 RDI: 0000000000000003
      RBP: 00000000006cc018 R08: 0000000000000100 R09: 0000000000000100
      R10: 0000000000000100 R11: 0000000000000207 R12: 0000000000402080
      R13: 0000000000402110 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:261 [inline]
       kmsan_internal_chain_origin+0x13d/0x240 mm/kmsan/kmsan.c:469
       kmsan_memcpy_memmove_metadata+0x1a9/0xf70 mm/kmsan/kmsan.c:344
       kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:362
       __msan_memcpy+0x61/0x70 mm/kmsan/kmsan_instr.c:162
       __nla_put lib/nlattr.c:744 [inline]
       nla_put+0x20a/0x2d0 lib/nlattr.c:802
       nlmsg_populate_fdb_fill+0x444/0x810 net/core/rtnetlink.c:3466
       nlmsg_populate_fdb net/core/rtnetlink.c:3775 [inline]
       ndo_dflt_fdb_dump+0x73a/0x960 net/core/rtnetlink.c:3807
       rtnl_fdb_dump+0x1318/0x1cb0 net/core/rtnetlink.c:3979
       netlink_dump+0xc79/0x1c90 net/netlink/af_netlink.c:2244
       __netlink_dump_start+0x10c4/0x11d0 net/netlink/af_netlink.c:2352
       netlink_dump_start include/linux/netlink.h:216 [inline]
       rtnetlink_rcv_msg+0x141b/0x1540 net/core/rtnetlink.c:4910
       netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116
       __sys_sendmsg net/socket.c:2154 [inline]
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
       kmsan_internal_poison_shadow+0x6d/0x130 mm/kmsan/kmsan.c:170
       kmsan_kmalloc+0xa1/0x100 mm/kmsan/kmsan_hooks.c:186
       __kmalloc+0x14c/0x4d0 mm/slub.c:3825
       kmalloc include/linux/slab.h:551 [inline]
       __hw_addr_create_ex net/core/dev_addr_lists.c:34 [inline]
       __hw_addr_add_ex net/core/dev_addr_lists.c:80 [inline]
       __dev_mc_add+0x357/0x8a0 net/core/dev_addr_lists.c:670
       dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
       ip_mc_filter_add net/ipv4/igmp.c:1128 [inline]
       igmp_group_added+0x4d4/0xb80 net/ipv4/igmp.c:1311
       __ip_mc_inc_group+0xea9/0xf70 net/ipv4/igmp.c:1444
       ip_mc_inc_group net/ipv4/igmp.c:1453 [inline]
       ip_mc_up+0x1c3/0x400 net/ipv4/igmp.c:1775
       inetdev_event+0x1d03/0x1d80 net/ipv4/devinet.c:1522
       notifier_call_chain kernel/notifier.c:93 [inline]
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x13d/0x240 kernel/notifier.c:401
       __dev_notify_flags+0x3da/0x860 net/core/dev.c:1733
       dev_change_flags+0x1ac/0x230 net/core/dev.c:7569
       do_setlink+0x165f/0x5ea0 net/core/rtnetlink.c:2492
       rtnl_newlink+0x2ad7/0x35a0 net/core/rtnetlink.c:3111
       rtnetlink_rcv_msg+0x1148/0x1540 net/core/rtnetlink.c:4947
       netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116
       __sys_sendmsg net/socket.c:2154 [inline]
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Bytes 36-37 of 105 are uninitialized
      Memory access of size 105 starts at ffff88819686c000
      Data copied to user address 0000000020000380
      
      Fixes: d83b0603 ("net: add fdb generic dump routine")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: 's avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe25279d
    • Christoph Paasch's avatar
      net: Prevent invalid access to skb->prev in __qdisc_drop_all · 8dd57cc3
      Christoph Paasch authored
      [ Upstream commit 9410d386d0a829ace9558336263086c2fbbe8aed ]
      
      __qdisc_drop_all() accesses skb->prev to get to the tail of the
      segment-list.
      
      With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
      the skb-list handling has been changed to set skb->next to NULL and set
      the list-poison on skb->prev.
      
      With that change, __qdisc_drop_all() will panic when it tries to
      dereference skb->prev.
      
      Since commit 992cba7e276d ("net: Add and use skb_list_del_init().")
      __list_del_entry is used, leaving skb->prev unchanged (thus,
      pointing to the list-head if it's the first skb of the list).
      This will make __qdisc_drop_all modify the next-pointer of the list-head
      and result in a panic later on:
      
      [   34.501053] general protection fault: 0000 [#1] SMP KASAN PTI
      [   34.501968] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.20.0-rc2.mptcp #108
      [   34.502887] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
      [   34.504074] RIP: 0010:dev_gro_receive+0x343/0x1f90
      [   34.504751] Code: e0 48 c1 e8 03 42 80 3c 30 00 0f 85 4a 1c 00 00 4d 8b 24 24 4c 39 65 d0 0f 84 0a 04 00 00 49 8d 7c 24 38 48 89 f8 48 c1 e8 03 <42> 0f b6 04 30 84 c0 74 08 3c 04
      [   34.507060] RSP: 0018:ffff8883af507930 EFLAGS: 00010202
      [   34.507761] RAX: 0000000000000007 RBX: ffff8883970b2c80 RCX: 1ffff11072e165a6
      [   34.508640] RDX: 1ffff11075867008 RSI: ffff8883ac338040 RDI: 0000000000000038
      [   34.509493] RBP: ffff8883af5079d0 R08: ffff8883970b2d40 R09: 0000000000000062
      [   34.510346] R10: 0000000000000034 R11: 0000000000000000 R12: 0000000000000000
      [   34.511215] R13: 0000000000000000 R14: dffffc0000000000 R15: ffff8883ac338008
      [   34.512082] FS:  0000000000000000(0000) GS:ffff8883af500000(0000) knlGS:0000000000000000
      [   34.513036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   34.513741] CR2: 000055ccc3e9d020 CR3: 00000003abf32000 CR4: 00000000000006e0
      [   34.514593] Call Trace:
      [   34.514893]  <IRQ>
      [   34.515157]  napi_gro_receive+0x93/0x150
      [   34.515632]  receive_buf+0x893/0x3700
      [   34.516094]  ? __netif_receive_skb+0x1f/0x1a0
      [   34.516629]  ? virtnet_probe+0x1b40/0x1b40
      [   34.517153]  ? __stable_node_chain+0x4d0/0x850
      [   34.517684]  ? kfree+0x9a/0x180
      [   34.518067]  ? __kasan_slab_free+0x171/0x190
      [   34.518582]  ? detach_buf+0x1df/0x650
      [   34.519061]  ? lapic_next_event+0x5a/0x90
      [   34.519539]  ? virtqueue_get_buf_ctx+0x280/0x7f0
      [   34.520093]  virtnet_poll+0x2df/0xd60
      [   34.520533]  ? receive_buf+0x3700/0x3700
      [   34.521027]  ? qdisc_watchdog_schedule_ns+0xd5/0x140
      [   34.521631]  ? htb_dequeue+0x1817/0x25f0
      [   34.522107]  ? sch_direct_xmit+0x142/0xf30
      [   34.522595]  ? virtqueue_napi_schedule+0x26/0x30
      [   34.523155]  net_rx_action+0x2f6/0xc50
      [   34.523601]  ? napi_complete_done+0x2f0/0x2f0
      [   34.524126]  ? kasan_check_read+0x11/0x20
      [   34.524608]  ? _raw_spin_lock+0x7d/0xd0
      [   34.525070]  ? _raw_spin_lock_bh+0xd0/0xd0
      [   34.525563]  ? kvm_guest_apic_eoi_write+0x6b/0x80
      [   34.526130]  ? apic_ack_irq+0x9e/0xe0
      [   34.526567]  __do_softirq+0x188/0x4b5
      [   34.527015]  irq_exit+0x151/0x180
      [   34.527417]  do_IRQ+0xdb/0x150
      [   34.527783]  common_interrupt+0xf/0xf
      [   34.528223]  </IRQ>
      
      This patch makes sure that skb->prev is set to NULL when entering
      netem_enqueue.
      
      Cc: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Fixes: 68d2f84a1368 ("net: gro: properly remove skb from list")
      Suggested-by: 's avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: 's avatarChristoph Paasch <cpaasch@apple.com>
      Reviewed-by: 's avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8dd57cc3
    • Stefano Brivio's avatar
      ipv6: Check available headroom in ip6_xmit() even without options · 901936a1
      Stefano Brivio authored
      [ Upstream commit 66033f47ca60294a95fc85ec3a3cc909dab7b765 ]
      
      Even if we send an IPv6 packet without options, MAX_HEADER might not be
      enough to account for the additional headroom required by alignment of
      hardware headers.
      
      On a configuration without HYPERV_NET, WLAN, AX25, and with IPV6_TUNNEL,
      sending short SCTP packets over IPv4 over L2TP over IPv6, we start with
      100 bytes of allocated headroom in sctp_packet_transmit(), end up with 54
      bytes after l2tp_xmit_skb(), and 14 bytes in ip6_finish_output2().
      
      Those would be enough to append our 14 bytes header, but we're going to
      align that to 16 bytes, and write 2 bytes out of the allocated slab in
      neigh_hh_output().
      
      KASan says:
      
      [  264.967848] ==================================================================
      [  264.967861] BUG: KASAN: slab-out-of-bounds in ip6_finish_output2+0x1aec/0x1c70
      [  264.967866] Write of size 16 at addr 000000006af1c7fe by task netperf/6201
      [  264.967870]
      [  264.967876] CPU: 0 PID: 6201 Comm: netperf Not tainted 4.20.0-rc4+ #1
      [  264.967881] Hardware name: IBM 2827 H43 400 (z/VM 6.4.0)
      [  264.967887] Call Trace:
      [  264.967896] ([<00000000001347d6>] show_stack+0x56/0xa0)
      [  264.967903]  [<00000000017e379c>] dump_stack+0x23c/0x290
      [  264.967912]  [<00000000007bc594>] print_address_description+0xf4/0x290
      [  264.967919]  [<00000000007bc8fc>] kasan_report+0x13c/0x240
      [  264.967927]  [<000000000162f5e4>] ip6_finish_output2+0x1aec/0x1c70
      [  264.967935]  [<000000000163f890>] ip6_finish_output+0x430/0x7f0
      [  264.967943]  [<000000000163fe44>] ip6_output+0x1f4/0x580
      [  264.967953]  [<000000000163882a>] ip6_xmit+0xfea/0x1ce8
      [  264.967963]  [<00000000017396e2>] inet6_csk_xmit+0x282/0x3f8
      [  264.968033]  [<000003ff805fb0ba>] l2tp_xmit_skb+0xe02/0x13e0 [l2tp_core]
      [  264.968037]  [<000003ff80631192>] l2tp_eth_dev_xmit+0xda/0x150 [l2tp_eth]
      [  264.968041]  [<0000000001220020>] dev_hard_start_xmit+0x268/0x928
      [  264.968069]  [<0000000001330e8e>] sch_direct_xmit+0x7ae/0x1350
      [  264.968071]  [<000000000122359c>] __dev_queue_xmit+0x2b7c/0x3478
      [  264.968075]  [<00000000013d2862>] ip_finish_output2+0xce2/0x11a0
      [  264.968078]  [<00000000013d9b14>] ip_finish_output+0x56c/0x8c8
      [  264.968081]  [<00000000013ddd1e>] ip_output+0x226/0x4c0
      [  264.968083]  [<00000000013dbd6c>] __ip_queue_xmit+0x894/0x1938
      [  264.968100]  [<000003ff80bc3a5c>] sctp_packet_transmit+0x29d4/0x3648 [sctp]
      [  264.968116]  [<000003ff80b7bf68>] sctp_outq_flush_ctrl.constprop.5+0x8d0/0xe50 [sctp]
      [  264.968131]  [<000003ff80b7c716>] sctp_outq_flush+0x22e/0x7d8 [sctp]
      [  264.968146]  [<000003ff80b35c68>] sctp_cmd_interpreter.isra.16+0x530/0x6800 [sctp]
      [  264.968161]  [<000003ff80b3410a>] sctp_do_sm+0x222/0x648 [sctp]
      [  264.968177]  [<000003ff80bbddac>] sctp_primitive_ASSOCIATE+0xbc/0xf8 [sctp]
      [  264.968192]  [<000003ff80b93328>] __sctp_connect+0x830/0xc20 [sctp]
      [  264.968208]  [<000003ff80bb11ce>] sctp_inet_connect+0x2e6/0x378 [sctp]
      [  264.968212]  [<0000000001197942>] __sys_connect+0x21a/0x450
      [  264.968215]  [<000000000119aff8>] sys_socketcall+0x3d0/0xb08
      [  264.968218]  [<000000000184ea7a>] system_call+0x2a2/0x2c0
      
      [...]
      
      Just like ip_finish_output2() does for IPv4, check that we have enough
      headroom in ip6_xmit(), and reallocate it if we don't.
      
      This issue is older than git history.
      Reported-by: 's avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: 's avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      901936a1
  2. 13 Dec, 2018 6 commits
  3. 08 Dec, 2018 12 commits
  4. 05 Dec, 2018 1 commit
    • Petr Machata's avatar
      net: skb_scrub_packet(): Scrub offload_fwd_mark · d39ebd19
      Petr Machata authored
      [ Upstream commit b5dd186d10ba59e6b5ba60e42b3b083df56df6f3 ]
      
      When a packet is trapped and the corresponding SKB marked as
      already-forwarded, it retains this marking even after it is forwarded
      across veth links into another bridge. There, since it ingresses the
      bridge over veth, which doesn't have offload_fwd_mark, it triggers a
      warning in nbp_switchdev_frame_mark().
      
      Then nbp_switchdev_allowed_egress() decides not to allow egress from
      this bridge through another veth, because the SKB is already marked, and
      the mark (of 0) of course matches. Thus the packet is incorrectly
      blocked.
      
      Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That
      function is called from tunnels and also from veth, and thus catches the
      cases where traffic is forwarded between bridges and transformed in a
      way that invalidates the marking.
      
      Fixes: 6bc506b4 ("bridge: switchdev: Add forward mark support for stacked devices")
      Fixes: abf4bb6b ("skbuff: Add the offload_mr_fwd_mark field")
      Signed-off-by: 's avatarPetr Machata <petrm@mellanox.com>
      Suggested-by: 's avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: 's avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d39ebd19
  5. 01 Dec, 2018 4 commits
    • Alexander Aring's avatar
      net: ieee802154: 6lowpan: fix frag reassembly · a49f0347
      Alexander Aring authored
      commit f18fa5de5ba7f1d6650951502bb96a6e4715a948 upstream.
      
      This patch initialize stack variables which are used in
      frag_lowpan_compare_key to zero. In my case there are padding bytes in the
      structures ieee802154_addr as well in frag_lowpan_compare_key. Otherwise
      the key variable contains random bytes. The result is that a compare of
      two keys by memcmp works incorrect.
      
      Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units")
      Signed-off-by: 's avatarAlexander Aring <aring@mojatatu.com>
      Reported-by: 's avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: 's avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a49f0347
    • Trond Myklebust's avatar
      SUNRPC: Fix a bogus get/put in generic_key_to_expire() · 35a0620f
      Trond Myklebust authored
      [ Upstream commit e3d5e573a54dabdc0f9f3cb039d799323372b251 ]
      Signed-off-by: 's avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      35a0620f
    • Eric Dumazet's avatar
      llc: do not use sk_eat_skb() · 2a122004
      Eric Dumazet authored
      commit 604d415e2bd642b7e02c80e719e0396b9d4a77a6 upstream.
      
      syzkaller triggered a use-after-free [1], caused by a combination of
      skb_get() in llc_conn_state_process() and usage of sk_eat_skb()
      
      sk_eat_skb() is assuming the skb about to be freed is only used by
      the current thread. TCP/DCCP stacks enforce this because current
      thread holds the socket lock.
      
      llc_conn_state_process() wants to make sure skb does not disappear,
      and holds a reference on the skb it manipulates. But as soon as this
      skb is added to socket receive queue, another thread can consume it.
      
      This means that llc must use regular skb_unlink() and kfree_skb()
      so that both producer and consumer can safely work on the same skb.
      
      [1]
      BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
      BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:43 [inline]
      BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:967 [inline]
      BUG: KASAN: use-after-free in kfree_skb+0xb7/0x580 net/core/skbuff.c:655
      Read of size 4 at addr ffff8801d1f6fba4 by task ksoftirqd/1/18
      
      CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.19.0-rc8+ #295
      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+0x1c4/0x2b6 lib/dump_stack.c:113
       print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.9+0x242/0x309 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
       kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
       atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
       refcount_read include/linux/refcount.h:43 [inline]
       skb_unref include/linux/skbuff.h:967 [inline]
       kfree_skb+0xb7/0x580 net/core/skbuff.c:655
       llc_sap_state_process+0x9b/0x550 net/llc/llc_sap.c:224
       llc_sap_rcv+0x156/0x1f0 net/llc/llc_sap.c:297
       llc_sap_handler+0x65e/0xf80 net/llc/llc_sap.c:438
       llc_rcv+0x79e/0xe20 net/llc/llc_input.c:208
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
       process_backlog+0x218/0x6f0 net/core/dev.c:5829
       napi_poll net/core/dev.c:6249 [inline]
       net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
       __do_softirq+0x30c/0xb03 kernel/softirq.c:292
       run_ksoftirqd+0x94/0x100 kernel/softirq.c:653
       smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
       kthread+0x35a/0x420 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
      
      Allocated by task 18:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
       kmem_cache_alloc_node+0x144/0x730 mm/slab.c:3644
       __alloc_skb+0x119/0x770 net/core/skbuff.c:193
       alloc_skb include/linux/skbuff.h:995 [inline]
       llc_alloc_frame+0xbc/0x370 net/llc/llc_sap.c:54
       llc_station_ac_send_xid_r net/llc/llc_station.c:52 [inline]
       llc_station_rcv+0x1dc/0x1420 net/llc/llc_station.c:111
       llc_rcv+0xc32/0xe20 net/llc/llc_input.c:220
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
       process_backlog+0x218/0x6f0 net/core/dev.c:5829
       napi_poll net/core/dev.c:6249 [inline]
       net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
       __do_softirq+0x30c/0xb03 kernel/softirq.c:292
      
      Freed by task 16383:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
       kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
       __cache_free mm/slab.c:3498 [inline]
       kmem_cache_free+0x83/0x290 mm/slab.c:3756
       kfree_skbmem+0x154/0x230 net/core/skbuff.c:582
       __kfree_skb+0x1d/0x20 net/core/skbuff.c:642
       sk_eat_skb include/net/sock.h:2366 [inline]
       llc_ui_recvmsg+0xec2/0x1610 net/llc/af_llc.c:882
       sock_recvmsg_nosec net/socket.c:794 [inline]
       sock_recvmsg+0xd0/0x110 net/socket.c:801
       ___sys_recvmsg+0x2b6/0x680 net/socket.c:2278
       __sys_recvmmsg+0x303/0xb90 net/socket.c:2390
       do_sys_recvmmsg+0x181/0x1a0 net/socket.c:2466
       __do_sys_recvmmsg net/socket.c:2484 [inline]
       __se_sys_recvmmsg net/socket.c:2480 [inline]
       __x64_sys_recvmmsg+0xbe/0x150 net/socket.c:2480
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8801d1f6fac0
       which belongs to the cache skbuff_head_cache of size 232
      The buggy address is located 228 bytes inside of
       232-byte region [ffff8801d1f6fac0, ffff8801d1f6fba8)
      The buggy address belongs to the page:
      page:ffffea000747dbc0 count:1 mapcount:0 mapping:ffff8801d9be7680 index:0xffff8801d1f6fe80
      flags: 0x2fffc0000000100(slab)
      raw: 02fffc0000000100 ffffea0007346e88 ffffea000705b108 ffff8801d9be7680
      raw: ffff8801d1f6fe80 ffff8801d1f6f0c0 000000010000000b 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8801d1f6fa80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
       ffff8801d1f6fb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8801d1f6fb80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
                                     ^
       ffff8801d1f6fc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8801d1f6fc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a122004
    • Xin Long's avatar
      sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer · e044554e
      Xin Long authored
      commit df132eff463873e14e019a07f387b4d577d6d1f9 upstream.
      
      If a transport is removed by asconf but there still are some chunks with
      this transport queuing on out_chunk_list, later an use-after-free issue
      will be caused when accessing this transport from these chunks in
      sctp_outq_flush().
      
      This is an old bug, we fix it by clearing the transport of these chunks
      in out_chunk_list when removing a transport in sctp_assoc_rm_peer().
      
      Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e044554e
  6. 27 Nov, 2018 4 commits
    • Ilya Dryomov's avatar
      libceph: fall back to sendmsg for slab pages · c3ec4e5b
      Ilya Dryomov authored
      commit 7e241f647dc7087a0401418a187f3f5b527cc690 upstream.
      
      skb_can_coalesce() allows coalescing neighboring slab objects into
      a single frag:
      
        return page == skb_frag_page(frag) &&
               off == frag->page_offset + skb_frag_size(frag);
      
      ceph_tcp_sendpage() can be handed slab pages.  One example of this is
      XFS: it passes down sector sized slab objects for its metadata I/O.  If
      the kernel client is co-located on the OSD node, the skb may go through
      loopback and pop on the receive side with the exact same set of frags.
      When tcp_recvmsg() attempts to copy out such a frag, hardened usercopy
      complains because the size exceeds the object's allocated size:
      
        usercopy: kernel memory exposure attempt detected from ffff9ba917f20a00 (kmalloc-512) (1024 bytes)
      
      Although skb_can_coalesce() could be taught to return false if the
      resulting frag would cross a slab object boundary, we already have
      a fallback for non-refcounted pages.  Utilize it for slab pages too.
      
      Cc: stable@vger.kernel.org # 4.8+
      Signed-off-by: 's avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3ec4e5b
    • YueHaibing's avatar
      SUNRPC: drop pointless static qualifier in xdr_get_next_encode_buffer() · a38ad671
      YueHaibing authored
      [ Upstream commit 025911a5f4e36955498ed50806ad1b02f0f76288 ]
      
      There is no need to have the '__be32 *p' variable static since new value
      always be assigned before use it.
      Signed-off-by: 's avatarYueHaibing <yuehaibing@huawei.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      a38ad671
    • Taehee Yoo's avatar
      netfilter: xt_IDLETIMER: add sysfs filename checking routine · f184d303
      Taehee Yoo authored
      [ Upstream commit 54451f60c8fa061af9051a53be9786393947367c ]
      
      When IDLETIMER rule is added, sysfs file is created under
      /sys/class/xt_idletimer/timers/
      But some label name shouldn't be used.
      ".", "..", "power", "uevent", "subsystem", etc...
      So that sysfs filename checking routine is needed.
      
      test commands:
         %iptables -I INPUT -j IDLETIMER --timeout 1 --label "power"
      
      splat looks like:
      [95765.423132] sysfs: cannot create duplicate filename '/devices/virtual/xt_idletimer/timers/power'
      [95765.433418] CPU: 0 PID: 8446 Comm: iptables Not tainted 4.19.0-rc6+ #20
      [95765.449755] Call Trace:
      [95765.449755]  dump_stack+0xc9/0x16b
      [95765.449755]  ? show_regs_print_info+0x5/0x5
      [95765.449755]  sysfs_warn_dup+0x74/0x90
      [95765.449755]  sysfs_add_file_mode_ns+0x352/0x500
      [95765.449755]  sysfs_create_file_ns+0x179/0x270
      [95765.449755]  ? sysfs_add_file_mode_ns+0x500/0x500
      [95765.449755]  ? idletimer_tg_checkentry+0x3e5/0xb1b [xt_IDLETIMER]
      [95765.449755]  ? rcu_read_lock_sched_held+0x114/0x130
      [95765.449755]  ? __kmalloc_track_caller+0x211/0x2b0
      [95765.449755]  ? memcpy+0x34/0x50
      [95765.449755]  idletimer_tg_checkentry+0x4e2/0xb1b [xt_IDLETIMER]
      [ ... ]
      
      Fixes: 0902b469 ("netfilter: xtables: idletimer target implementation")
      Signed-off-by: 's avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: 's avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f184d303
    • Eric Westbrook's avatar
      netfilter: ipset: actually allow allowable CIDR 0 in hash:net,port,net · 919560af
      Eric Westbrook authored
      [ Upstream commit 886503f34d63e681662057448819edb5b1057a97 ]
      
      Allow /0 as advertised for hash:net,port,net sets.
      
      For "hash:net,port,net", ipset(8) says that "either subnet
      is permitted to be a /0 should you wish to match port
      between all destinations."
      
      Make that statement true.
      
      Before:
      
          # ipset create cidrzero hash:net,port,net
          # ipset add cidrzero 0.0.0.0/0,12345,0.0.0.0/0
          ipset v6.34: The value of the CIDR parameter of the IP address is invalid
      
          # ipset create cidrzero6 hash:net,port,net family inet6
          # ipset add cidrzero6 ::/0,12345,::/0
          ipset v6.34: The value of the CIDR parameter of the IP address is invalid
      
      After:
      
          # ipset create cidrzero hash:net,port,net
          # ipset add cidrzero 0.0.0.0/0,12345,0.0.0.0/0
          # ipset test cidrzero 192.168.205.129,12345,172.16.205.129
          192.168.205.129,tcp:12345,172.16.205.129 is in set cidrzero.
      
          # ipset create cidrzero6 hash:net,port,net family inet6
          # ipset add cidrzero6 ::/0,12345,::/0
          # ipset test cidrzero6 fe80::1,12345,ff00::1
          fe80::1,tcp:12345,ff00::1 is in set cidrzero6.
      
      See also:
      
        https://bugzilla.kernel.org/show_bug.cgi?id=200897
        https://github.com/ewestbrook/linux/commit/df7ff6efb0934ab6acc11f003ff1a7580d6c1d9cSigned-off-by: 's avatarEric Westbrook <linux@westbrook.io>
      Signed-off-by: 's avatarJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: 's avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      919560af
  7. 23 Nov, 2018 7 commits
  8. 21 Nov, 2018 1 commit