1. 09 Jan, 2019 15 commits
    • Willem de Bruijn's avatar
      packet: validate address length · 9eee85ed
      Willem de Bruijn authored
      [ Upstream commit 99137b78 ]
      
      Packet sockets with SOCK_DGRAM may pass an address for use in
      dev_hard_header. Ensure that it is of sufficient length.
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9eee85ed
    • Cong Wang's avatar
      net/wan: fix a double free in x25_asy_open_tty() · 65b34802
      Cong Wang authored
      [ Upstream commit d5c7c745 ]
      
      When x25_asy_open() fails, it already cleans up by itself,
      so its caller doesn't need to free the memory again.
      
      It seems we still have to call x25_asy_free() to clear the SLF_INUSE
      bit, so just set these pointers to NULL after kfree().
      
      Reported-and-tested-by: syzbot+5e5e969e525129229052@syzkaller.appspotmail.com
      Fixes: 3b780bed ("x25_asy: Free x25_asy on x25_asy_open() failure.")
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      65b34802
    • Cong Wang's avatar
      netrom: fix locking in nr_find_socket() · bb98e55e
      Cong Wang authored
      [ Upstream commit 7314f548 ]
      
      nr_find_socket(), nr_find_peer() and nr_find_listener() lock the
      sock after finding it in the global list. However, the call path
      requires BH disabled for the sock lock consistently.
      
      Actually the locking is unnecessary at this point, we can just hold
      the sock refcnt to make sure it is not gone after we unlock the global
      list, and lock it later only when needed.
      
      Reported-and-tested-by: syzbot+f621cda8b7e598908efa@syzkaller.appspotmail.com
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb98e55e
    • Kunihiko Hayashi's avatar
      net: phy: Fix the issue that netif always links up after resuming · 309bc341
      Kunihiko Hayashi authored
      [ Upstream commit 8742beb5 ]
      
      Even though the link is down before entering hibernation,
      there is an issue that the network interface always links up after resuming
      from hibernation.
      
      If the link is still down before enabling the network interface,
      and after resuming from hibernation, the phydev->state is forcibly set
      to PHY_UP in mdio_bus_phy_restore(), and the link becomes up.
      
      In suspend sequence, only if the PHY is attached, mdio_bus_phy_suspend()
      calls phy_stop_machine(), and mdio_bus_phy_resume() calls
      phy_start_machine().
      In resume sequence, it's enough to do the same as mdio_bus_phy_resume()
      because the state has been preserved.
      
      This patch fixes the issue by calling phy_start_machine() in
      mdio_bus_phy_restore() in the same way as mdio_bus_phy_resume().
      
      Fixes: bc87922f ("phy: Move PHY PM operations into phy_device")
      Suggested-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarKunihiko Hayashi <hayashi.kunihiko@socionext.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      309bc341
    • Claudiu Beznea's avatar
      net: macb: restart tx after tx used bit read · 6e12baae
      Claudiu Beznea authored
      [ Upstream commit 42983885 ]
      
      On some platforms (currently detected only on SAMA5D4) TX might stuck
      even the pachets are still present in DMA memories and TX start was
      issued for them. This happens due to race condition between MACB driver
      updating next TX buffer descriptor to be used and IP reading the same
      descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted.
      GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt
      is asserted TX must be restarted. Restart TX if used bit is read and
      packets are present in software TX queue. Packets are removed from software
      TX queue if TX was successful for them (see macb_tx_interrupt()).
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e12baae
    • Michal Kubecek's avatar
      net: ipv4: do not handle duplicate fragments as overlapping · 95b4b711
      Michal Kubecek authored
      [ Upstream commit ade44640 ]
      
      Since commit 7969e5c4 ("ip: discard IPv4 datagrams with overlapping
      segments.") IPv4 reassembly code drops the whole queue whenever an
      overlapping fragment is received. However, the test is written in a way
      which detects duplicate fragments as overlapping so that in environments
      with many duplicate packets, fragmented packets may be undeliverable.
      
      Add an extra test and for (potentially) duplicate fragment, only drop the
      new fragment rather than the whole queue. Only starting offset and length
      are checked, not the contents of the fragments as that would be too
      expensive. For similar reason, linear list ("run") of a rbtree node is not
      iterated, we only check if the new fragment is a subset of the interval
      covered by existing consecutive fragments.
      
      v2: instead of an exact check iterating through linear list of an rbtree
      node, only check if the new fragment is subset of the "run" (suggested
      by Eric Dumazet)
      
      Fixes: 7969e5c4 ("ip: discard IPv4 datagrams with overlapping segments.")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95b4b711
    • Eric Dumazet's avatar
      isdn: fix kernel-infoleak in capi_unlocked_ioctl · 1e9f6b66
      Eric Dumazet authored
      [ Upstream commit d63967e4 ]
      
      Since capi_ioctl() copies 64 bytes after calling
      capi20_get_manufacturer() we need to ensure to not leak
      information to user.
      
      BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
      CPU: 0 PID: 11245 Comm: syz-executor633 Not tainted 4.20.0-rc7+ #2
      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+0x173/0x1d0 lib/dump_stack.c:113
       kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
       kmsan_internal_check_memory+0x9d4/0xb00 mm/kmsan/kmsan.c:704
       kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
       _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
       capi_ioctl include/linux/uaccess.h:177 [inline]
       capi_unlocked_ioctl+0x1a0b/0x1bf0 drivers/isdn/capi/capi.c:939
       do_vfs_ioctl+0xebd/0x2bf0 fs/ioctl.c:46
       ksys_ioctl fs/ioctl.c:713 [inline]
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718
       __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x440019
      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 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffdd4659fb8 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440019
      RDX: 0000000020000080 RSI: 00000000c0044306 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
      R10: 0000000000000000 R11: 0000000000000213 R12: 00000000004018a0
      R13: 0000000000401930 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----data.i@capi_unlocked_ioctl
      Variable was created at:
       capi_ioctl drivers/isdn/capi/capi.c:747 [inline]
       capi_unlocked_ioctl+0x82/0x1bf0 drivers/isdn/capi/capi.c:939
       do_vfs_ioctl+0xebd/0x2bf0 fs/ioctl.c:46
      
      Bytes 12-63 of 64 are uninitialized
      Memory access of size 64 starts at ffff88807ac5fce8
      Data copied to user address 0000000020000080
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e9f6b66
    • Eric Dumazet's avatar
      ipv6: tunnels: fix two use-after-free · 64d22404
      Eric Dumazet authored
      [ Upstream commit cbb49697 ]
      
      xfrm6_policy_check() might have re-allocated skb->head, we need
      to reload ipv6 header pointer.
      
      sysbot reported :
      
      BUG: KASAN: use-after-free in __ipv6_addr_type+0x302/0x32f net/ipv6/addrconf_core.c:40
      Read of size 4 at addr ffff888191b8cb70 by task syz-executor2/1304
      
      CPU: 0 PID: 1304 Comm: syz-executor2 Not tainted 4.20.0-rc7+ #356
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x244/0x39d lib/dump_stack.c:113
       print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
       __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
       __ipv6_addr_type+0x302/0x32f net/ipv6/addrconf_core.c:40
       ipv6_addr_type include/net/ipv6.h:403 [inline]
       ip6_tnl_get_cap+0x27/0x190 net/ipv6/ip6_tunnel.c:727
       ip6_tnl_rcv_ctl+0xdb/0x2a0 net/ipv6/ip6_tunnel.c:757
       vti6_rcv+0x336/0x8f3 net/ipv6/ip6_vti.c:321
       xfrm6_ipcomp_rcv+0x1a5/0x3a0 net/ipv6/xfrm6_protocol.c:132
       ip6_protocol_deliver_rcu+0x372/0x1940 net/ipv6/ip6_input.c:394
       ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:434
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:443
      IPVS: ftp: loaded support on port[0] = 21
       ip6_mc_input+0x514/0x11c0 net/ipv6/ip6_input.c:537
       dst_input include/net/dst.h:450 [inline]
       ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ipv6_rcv+0x115/0x640 net/ipv6/ip6_input.c:272
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4973
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5083
       process_backlog+0x24e/0x7a0 net/core/dev.c:5923
       napi_poll net/core/dev.c:6346 [inline]
       net_rx_action+0x7fa/0x19b0 net/core/dev.c:6412
       __do_softirq+0x308/0xb7e kernel/softirq.c:292
       do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027
       </IRQ>
       do_softirq.part.14+0x126/0x160 kernel/softirq.c:337
       do_softirq+0x19/0x20 kernel/softirq.c:340
       netif_rx_ni+0x521/0x860 net/core/dev.c:4569
       dev_loopback_xmit+0x287/0x8c0 net/core/dev.c:3576
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip6_finish_output2+0x193a/0x2930 net/ipv6/ip6_output.c:84
       ip6_fragment+0x2b06/0x3850 net/ipv6/ip6_output.c:727
       ip6_finish_output+0x6b7/0xc50 net/ipv6/ip6_output.c:152
       NF_HOOK_COND include/linux/netfilter.h:278 [inline]
       ip6_output+0x232/0x9d0 net/ipv6/ip6_output.c:171
       dst_output include/net/dst.h:444 [inline]
       ip6_local_out+0xc5/0x1b0 net/ipv6/output_core.c:176
       ip6_send_skb+0xbc/0x340 net/ipv6/ip6_output.c:1727
       ip6_push_pending_frames+0xc5/0xf0 net/ipv6/ip6_output.c:1747
       rawv6_push_pending_frames net/ipv6/raw.c:615 [inline]
       rawv6_sendmsg+0x3a3e/0x4b40 net/ipv6/raw.c:945
      kobject: 'queues' (0000000089e6eea2): kobject_add_internal: parent: 'tunl0', set: '<NULL>'
      kobject: 'queues' (0000000089e6eea2): kobject_uevent_env
       inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
      kobject: 'queues' (0000000089e6eea2): kobject_uevent_env: filter function caused the event to drop!
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:631
       sock_write_iter+0x35e/0x5c0 net/socket.c:900
       call_write_iter include/linux/fs.h:1857 [inline]
       new_sync_write fs/read_write.c:474 [inline]
       __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
      kobject: 'rx-0' (00000000e2d902d9): kobject_add_internal: parent: 'queues', set: 'queues'
      kobject: 'rx-0' (00000000e2d902d9): kobject_uevent_env
       vfs_write+0x1fc/0x560 fs/read_write.c:549
       ksys_write+0x101/0x260 fs/read_write.c:598
      kobject: 'rx-0' (00000000e2d902d9): fill_kobj_path: path = '/devices/virtual/net/tunl0/queues/rx-0'
       __do_sys_write fs/read_write.c:610 [inline]
       __se_sys_write fs/read_write.c:607 [inline]
       __x64_sys_write+0x73/0xb0 fs/read_write.c:607
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
      kobject: 'tx-0' (00000000443b70ac): kobject_add_internal: parent: 'queues', set: 'queues'
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457669
      Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f9bd200bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457669
      RDX: 000000000000058f RSI: 00000000200033c0 RDI: 0000000000000003
      kobject: 'tx-0' (00000000443b70ac): kobject_uevent_env
      RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9bd200c6d4
      R13: 00000000004c2dcc R14: 00000000004da398 R15: 00000000ffffffff
      
      Allocated by task 1304:
       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
       __do_kmalloc_node mm/slab.c:3684 [inline]
       __kmalloc_node_track_caller+0x50/0x70 mm/slab.c:3698
       __kmalloc_reserve.isra.41+0x41/0xe0 net/core/skbuff.c:140
       __alloc_skb+0x155/0x760 net/core/skbuff.c:208
      kobject: 'tx-0' (00000000443b70ac): fill_kobj_path: path = '/devices/virtual/net/tunl0/queues/tx-0'
       alloc_skb include/linux/skbuff.h:1011 [inline]
       __ip6_append_data.isra.49+0x2f1a/0x3f50 net/ipv6/ip6_output.c:1450
       ip6_append_data+0x1bc/0x2d0 net/ipv6/ip6_output.c:1619
       rawv6_sendmsg+0x15ab/0x4b40 net/ipv6/raw.c:938
       inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:631
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116
       __sys_sendmsg+0x11d/0x280 net/socket.c:2154
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg net/socket.c:2161 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      kobject: 'gre0' (00000000cb1b2d7b): kobject_add_internal: parent: 'net', set: 'devices'
      
      Freed by task 1304:
       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]
       kfree+0xcf/0x230 mm/slab.c:3817
       skb_free_head+0x93/0xb0 net/core/skbuff.c:553
       pskb_expand_head+0x3b2/0x10d0 net/core/skbuff.c:1498
       __pskb_pull_tail+0x156/0x18a0 net/core/skbuff.c:1896
       pskb_may_pull include/linux/skbuff.h:2188 [inline]
       _decode_session6+0xd11/0x14d0 net/ipv6/xfrm6_policy.c:150
       __xfrm_decode_session+0x71/0x140 net/xfrm/xfrm_policy.c:3272
      kobject: 'gre0' (00000000cb1b2d7b): kobject_uevent_env
       __xfrm_policy_check+0x380/0x2c40 net/xfrm/xfrm_policy.c:3322
       __xfrm_policy_check2 include/net/xfrm.h:1170 [inline]
       xfrm_policy_check include/net/xfrm.h:1175 [inline]
       xfrm6_policy_check include/net/xfrm.h:1185 [inline]
       vti6_rcv+0x4bd/0x8f3 net/ipv6/ip6_vti.c:316
       xfrm6_ipcomp_rcv+0x1a5/0x3a0 net/ipv6/xfrm6_protocol.c:132
       ip6_protocol_deliver_rcu+0x372/0x1940 net/ipv6/ip6_input.c:394
       ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:434
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:443
       ip6_mc_input+0x514/0x11c0 net/ipv6/ip6_input.c:537
       dst_input include/net/dst.h:450 [inline]
       ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ipv6_rcv+0x115/0x640 net/ipv6/ip6_input.c:272
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4973
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5083
       process_backlog+0x24e/0x7a0 net/core/dev.c:5923
      kobject: 'gre0' (00000000cb1b2d7b): fill_kobj_path: path = '/devices/virtual/net/gre0'
       napi_poll net/core/dev.c:6346 [inline]
       net_rx_action+0x7fa/0x19b0 net/core/dev.c:6412
       __do_softirq+0x308/0xb7e kernel/softirq.c:292
      
      The buggy address belongs to the object at ffff888191b8cac0
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 176 bytes inside of
       512-byte region [ffff888191b8cac0, ffff888191b8ccc0)
      The buggy address belongs to the page:
      page:ffffea000646e300 count:1 mapcount:0 mapping:ffff8881da800940 index:0x0
      flags: 0x2fffc0000000200(slab)
      raw: 02fffc0000000200 ffffea0006eaaa48 ffffea00065356c8 ffff8881da800940
      raw: 0000000000000000 ffff888191b8c0c0 0000000100000006 0000000000000000
      page dumped because: kasan: bad access detected
      kobject: 'queues' (000000005fd6226e): kobject_add_internal: parent: 'gre0', set: '<NULL>'
      
      Memory state around the buggy address:
       ffff888191b8ca00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff888191b8ca80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
      >ffff888191b8cb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                   ^
       ffff888191b8cb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff888191b8cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 0d3c703a ("ipv6: Cleanup IPv6 tunnel receive path")
      Fixes: ed1efb2a ("ipv6: Add support for IPsec virtual tunnel interfaces")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64d22404
    • Cong Wang's avatar
      ipv6: explicitly initialize udp6_addr in udp_sock_create6() · c68815c1
      Cong Wang authored
      [ Upstream commit fb242745 ]
      
      syzbot reported the use of uninitialized udp6_addr::sin6_scope_id.
      We can just set ::sin6_scope_id to zero, as tunnels are unlikely
      to use an IPv6 address that needs a scope id and there is no
      interface to bind in this context.
      
      For net-next, it looks different as we have cfg->bind_ifindex there
      so we can probably call ipv6_iface_scope_id().
      
      Same for ::sin6_flowinfo, tunnels don't use it.
      
      Fixes: 8024e028 ("udp: Add udp_sock_create for UDP tunnels to open listener socket")
      Reported-by: syzbot+c56449ed3652e6720f30@syzkaller.appspotmail.com
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c68815c1
    • Willem de Bruijn's avatar
      ieee802154: lowpan_header_create check must check daddr · 59a3d2dc
      Willem de Bruijn authored
      [ Upstream commit 40c3ff6d ]
      
      Packet sockets may call dev_header_parse with NULL daddr. Make
      lowpan_header_ops.create fail.
      
      Fixes: 87a93e4e ("ieee802154: change needed headroom/tailroom")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarAlexander Aring <aring@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59a3d2dc
    • Tyrel Datwyler's avatar
      ibmveth: fix DMA unmap error in ibmveth_xmit_start error path · 8d349348
      Tyrel Datwyler authored
      [ Upstream commit 756af9c6 ]
      
      Commit 33a48ab1 ("ibmveth: Fix DMA unmap error") fixed an issue in the
      normal code path of ibmveth_xmit_start() that was originally introduced by
      Commit 6e8ab30e ("ibmveth: Add scatter-gather support"). This original
      fix missed the error path where dma_unmap_page is wrongly called on the
      header portion in descs[0] which was mapped with dma_map_single. As a
      result a failure to DMA map any of the frags results in a dmesg warning
      when CONFIG_DMA_API_DEBUG is enabled.
      
      ------------[ cut here ]------------
      DMA-API: ibmveth 30000002: device driver frees DMA memory with wrong function
        [device address=0x000000000a430000] [size=172 bytes] [mapped as page] [unmapped as single]
      WARNING: CPU: 1 PID: 8426 at kernel/dma/debug.c:1085 check_unmap+0x4fc/0xe10
      ...
      <snip>
      ...
      DMA-API: Mapped at:
      ibmveth_start_xmit+0x30c/0xb60
      dev_hard_start_xmit+0x100/0x450
      sch_direct_xmit+0x224/0x490
      __qdisc_run+0x20c/0x980
      __dev_queue_xmit+0x1bc/0xf20
      
      This fixes the API misuse by unampping descs[0] with dma_unmap_single.
      
      Fixes: 6e8ab30e ("ibmveth: Add scatter-gather support")
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d349348
    • Lorenzo Bianconi's avatar
      gro_cell: add napi_disable in gro_cells_destroy · 79d222d8
      Lorenzo Bianconi authored
      [ Upstream commit 8e1da73a ]
      
      Add napi_disable routine in gro_cells_destroy since starting from
      commit c42858ea ("gro_cells: remove spinlock protecting receive
      queues") gro_cell_poll and gro_cells_destroy can run concurrently on
      napi_skbs list producing a kernel Oops if the tunnel interface is
      removed while gro_cell_poll is running. The following Oops has been
      triggered removing a vxlan device while the interface is receiving
      traffic
      
      [ 5628.948853] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      [ 5628.949981] PGD 0 P4D 0
      [ 5628.950308] Oops: 0002 [#1] SMP PTI
      [ 5628.950748] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 4.20.0-rc6+ #41
      [ 5628.952940] RIP: 0010:gro_cell_poll+0x49/0x80
      [ 5628.955615] RSP: 0018:ffffc9000004fdd8 EFLAGS: 00010202
      [ 5628.956250] RAX: 0000000000000000 RBX: ffffe8ffffc08150 RCX: 0000000000000000
      [ 5628.957102] RDX: 0000000000000000 RSI: ffff88802356bf00 RDI: ffffe8ffffc08150
      [ 5628.957940] RBP: 0000000000000026 R08: 0000000000000000 R09: 0000000000000000
      [ 5628.958803] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000040
      [ 5628.959661] R13: ffffe8ffffc08100 R14: 0000000000000000 R15: 0000000000000040
      [ 5628.960682] FS:  0000000000000000(0000) GS:ffff88803ea00000(0000) knlGS:0000000000000000
      [ 5628.961616] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 5628.962359] CR2: 0000000000000008 CR3: 000000000221c000 CR4: 00000000000006b0
      [ 5628.963188] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 5628.964034] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 5628.964871] Call Trace:
      [ 5628.965179]  net_rx_action+0xf0/0x380
      [ 5628.965637]  __do_softirq+0xc7/0x431
      [ 5628.966510]  run_ksoftirqd+0x24/0x30
      [ 5628.966957]  smpboot_thread_fn+0xc5/0x160
      [ 5628.967436]  kthread+0x113/0x130
      [ 5628.968283]  ret_from_fork+0x3a/0x50
      [ 5628.968721] Modules linked in:
      [ 5628.969099] CR2: 0000000000000008
      [ 5628.969510] ---[ end trace 9d9dedc7181661fe ]---
      [ 5628.970073] RIP: 0010:gro_cell_poll+0x49/0x80
      [ 5628.972965] RSP: 0018:ffffc9000004fdd8 EFLAGS: 00010202
      [ 5628.973611] RAX: 0000000000000000 RBX: ffffe8ffffc08150 RCX: 0000000000000000
      [ 5628.974504] RDX: 0000000000000000 RSI: ffff88802356bf00 RDI: ffffe8ffffc08150
      [ 5628.975462] RBP: 0000000000000026 R08: 0000000000000000 R09: 0000000000000000
      [ 5628.976413] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000040
      [ 5628.977375] R13: ffffe8ffffc08100 R14: 0000000000000000 R15: 0000000000000040
      [ 5628.978296] FS:  0000000000000000(0000) GS:ffff88803ea00000(0000) knlGS:0000000000000000
      [ 5628.979327] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 5628.980044] CR2: 0000000000000008 CR3: 000000000221c000 CR4: 00000000000006b0
      [ 5628.980929] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 5628.981736] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 5628.982409] Kernel panic - not syncing: Fatal exception in interrupt
      [ 5628.983307] Kernel Offset: disabled
      
      Fixes: c42858ea ("gro_cells: remove spinlock protecting receive queues")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79d222d8
    • Cong Wang's avatar
      ax25: fix a use-after-free in ax25_fillin_cb() · 26a5adc8
      Cong Wang authored
      [ Upstream commit c4335704 ]
      
      There are multiple issues here:
      
      1. After freeing dev->ax25_ptr, we need to set it to NULL otherwise
         we may use a dangling pointer.
      
      2. There is a race between ax25_setsockopt() and device notifier as
         reported by syzbot. Close it by holding RTNL lock.
      
      3. We need to test if dev->ax25_ptr is NULL before using it.
      
      Reported-and-tested-by: syzbot+ae6bb869cbed29b29040@syzkaller.appspotmail.com
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26a5adc8
    • Gustavo A. R. Silva's avatar
      ip6mr: Fix potential Spectre v1 vulnerability · 18e260fd
      Gustavo A. R. Silva authored
      [ Upstream commit 69d2c867 ]
      
      vr.mifi is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      net/ipv6/ip6mr.c:1845 ip6mr_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      net/ipv6/ip6mr.c:1919 ip6mr_compat_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      
      Fix this by sanitizing vr.mifi before using it to index mrt->vif_table'
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18e260fd
    • Gustavo A. R. Silva's avatar
      ipv4: Fix potential Spectre v1 vulnerability · 26a697a9
      Gustavo A. R. Silva authored
      [ Upstream commit 5648451e ]
      
      vr.vifi is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      net/ipv4/ipmr.c:1616 ipmr_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      net/ipv4/ipmr.c:1690 ipmr_compat_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      
      Fix this by sanitizing vr.vifi before using it to index mrt->vif_table'
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26a697a9
  2. 29 Dec, 2018 25 commits