1. 19 Mar, 2019 23 commits
    • Jack Morgenstein's avatar
      net/mlx4_core: Fix locking in SRIOV mode when switching between events and polling · c3bcf8cb
      Jack Morgenstein authored
      [ Upstream commit c07d2792 ]
      
      In procedures mlx4_cmd_use_events() and mlx4_cmd_use_polling(), we need to
      guarantee that there are no FW commands in progress on the comm channel
      (for VFs) or wrapped FW commands (on the PF) when SRIOV is active.
      
      We do this by also taking the slave_cmd_mutex when SRIOV is active.
      
      This is especially important when switching from event to polling, since we
      free the command-context array during the switch.  If there are FW commands
      in progress (e.g., waiting for a completion event), the completion event
      handler will access freed memory.
      
      Since the decision to use comm_wait or comm_poll is taken before grabbing
      the event_sem/poll_sem in mlx4_comm_cmd_wait/poll, we must take the
      slave_cmd_mutex as well (to guarantee that the decision to use events or
      polling and the call to the appropriate cmd function are atomic).
      
      Fixes: a7e1f049 ("net/mlx4_core: Fix deadlock when switching between polling and event fw commands")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3bcf8cb
    • Jack Morgenstein's avatar
      net/mlx4_core: Fix reset flow when in command polling mode · 1f34d8d2
      Jack Morgenstein authored
      [ Upstream commit e15ce4b8 ]
      
      As part of unloading a device, the driver switches from
      FW command event mode to FW command polling mode.
      
      Part of switching over to polling mode is freeing the command context array
      memory (unfortunately, currently, without NULLing the command context array
      pointer).
      
      The reset flow calls "complete" to complete all outstanding fw commands
      (if we are in event mode). The check for event vs. polling mode here
      is to test if the command context array pointer is NULL.
      
      If the reset flow is activated after the switch to polling mode, it will
      attempt (incorrectly) to complete all the commands in the context array --
      because the pointer was not NULLed when the driver switched over to polling
      mode.
      
      As a result, we have a use-after-free situation, which results in a
      kernel crash.
      
      For example:
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff876c4a8e>] __wake_up_common+0x2e/0x90
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in: netconsole nfsv3 nfs_acl nfs lockd grace ...
      CPU: 2 PID: 940 Comm: kworker/2:3 Kdump: loaded Not tainted 3.10.0-862.el7.x86_64 #1
      Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  04/28/2016
      Workqueue: events hv_eject_device_work [pci_hyperv]
      task: ffff8d1734ca0fd0 ti: ffff8d17354bc000 task.ti: ffff8d17354bc000
      RIP: 0010:[<ffffffff876c4a8e>]  [<ffffffff876c4a8e>] __wake_up_common+0x2e/0x90
      RSP: 0018:ffff8d17354bfa38  EFLAGS: 00010082
      RAX: 0000000000000000 RBX: ffff8d17362d42c8 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8d17362d42c8
      RBP: ffff8d17354bfa70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000298 R11: ffff8d173610e000 R12: ffff8d17362d42d0
      R13: 0000000000000246 R14: 0000000000000000 R15: 0000000000000003
      FS:  0000000000000000(0000) GS:ffff8d1802680000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000000f16d8000 CR4: 00000000001406e0
      Call Trace:
       [<ffffffff876c7adc>] complete+0x3c/0x50
       [<ffffffffc04242f0>] mlx4_cmd_wake_completions+0x70/0x90 [mlx4_core]
       [<ffffffffc041e7b1>] mlx4_enter_error_state+0xe1/0x380 [mlx4_core]
       [<ffffffffc041fa4b>] mlx4_comm_cmd+0x29b/0x360 [mlx4_core]
       [<ffffffffc041ff51>] __mlx4_cmd+0x441/0x920 [mlx4_core]
       [<ffffffff877f62b1>] ? __slab_free+0x81/0x2f0
       [<ffffffff87951384>] ? __radix_tree_lookup+0x84/0xf0
       [<ffffffffc043a8eb>] mlx4_free_mtt_range+0x5b/0xb0 [mlx4_core]
       [<ffffffffc043a957>] mlx4_mtt_cleanup+0x17/0x20 [mlx4_core]
       [<ffffffffc04272c7>] mlx4_free_eq+0xa7/0x1c0 [mlx4_core]
       [<ffffffffc042803e>] mlx4_cleanup_eq_table+0xde/0x130 [mlx4_core]
       [<ffffffffc0433e08>] mlx4_unload_one+0x118/0x300 [mlx4_core]
       [<ffffffffc0434191>] mlx4_remove_one+0x91/0x1f0 [mlx4_core]
      
      The fix is to set the command context array pointer to NULL after freeing
      the array.
      
      Fixes: f5aef5aa ("net/mlx4_core: Activate reset flow upon fatal command cases")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f34d8d2
    • Eric Dumazet's avatar
      vxlan: test dev->flags & IFF_UP before calling gro_cells_receive() · f09a656b
      Eric Dumazet authored
      [ Upstream commit 59cbf56f ]
      
      Same reasons than the ones explained in commit 4179cb5a
      ("vxlan: test dev->flags & IFF_UP before calling netif_rx()")
      
      netif_rx() or gro_cells_receive() must be called under a strict contract.
      
      At device dismantle phase, core networking clears IFF_UP
      and flush_all_backlogs() is called after rcu grace period
      to make sure no incoming packet might be in a cpu backlog
      and still referencing the device.
      
      A similar protocol is used for gro_cells infrastructure, as
      gro_cells_destroy() will be called only after a full rcu
      grace period is observed after IFF_UP has been cleared.
      
      Most drivers call netif_rx() from their interrupt handler,
      and since the interrupts are disabled at device dismantle,
      netif_rx() does not have to check dev->flags & IFF_UP
      
      Virtual drivers do not have this guarantee, and must
      therefore make the check themselves.
      
      Otherwise we risk use-after-free and/or crashes.
      
      Fixes: d342894c ("vxlan: virtual extensible lan")
      Signed-off-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>
      f09a656b
    • Stefano Brivio's avatar
      vxlan: Fix GRO cells race condition between receive and link delete · 9f7aeee6
      Stefano Brivio authored
      [ Upstream commit ad6c9986 ]
      
      If we receive a packet while deleting a VXLAN device, there's a chance
      vxlan_rcv() is called at the same time as vxlan_dellink(). This is fine,
      except that vxlan_dellink() should never ever touch stuff that's still in
      use, such as the GRO cells list.
      
      Otherwise, vxlan_rcv() crashes while queueing packets via
      gro_cells_receive().
      
      Move the gro_cells_destroy() to vxlan_uninit(), which runs after the RCU
      grace period is elapsed and nothing needs the gro_cells anymore.
      
      This is now done in the same way as commit 8e816df8 ("geneve: Use GRO
      cells infrastructure.") originally implemented for GENEVE.
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Fixes: 58ce31cc ("vxlan: GRO support at tunnel layer")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-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>
      9f7aeee6
    • Guillaume Nault's avatar
      tcp: handle inet_csk_reqsk_queue_add() failures · 173e9023
      Guillaume Nault authored
      [  Upstream commit 9d3e1368 ]
      
      Commit 7716682c ("tcp/dccp: fix another race at listener
      dismantle") let inet_csk_reqsk_queue_add() fail, and adjusted
      {tcp,dccp}_check_req() accordingly. However, TFO and syncookies
      weren't modified, thus leaking allocated resources on error.
      
      Contrary to tcp_check_req(), in both syncookies and TFO cases,
      we need to drop the request socket. Also, since the child socket is
      created with inet_csk_clone_lock(), we have to unlock it and drop an
      extra reference (->sk_refcount is initially set to 2 and
      inet_csk_reqsk_queue_add() drops only one ref).
      
      For TFO, we also need to revert the work done by tcp_try_fastopen()
      (with reqsk_fastopen_remove()).
      
      Fixes: 7716682c ("tcp/dccp: fix another race at listener dismantle")
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-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>
      173e9023
    • Christoph Paasch's avatar
      tcp: Don't access TCP_SKB_CB before initializing it · fba43f49
      Christoph Paasch authored
      [ Upstream commit f2feaefd ]
      
      Since commit eeea10b8 ("tcp: add
      tcp_v4_fill_cb()/tcp_v4_restore_cb()"), tcp_vX_fill_cb is only called
      after tcp_filter(). That means, TCP_SKB_CB(skb)->end_seq still points to
      the IP-part of the cb.
      
      We thus should not mock with it, as this can trigger bugs (thanks
      syzkaller):
      [   12.349396] ==================================================================
      [   12.350188] BUG: KASAN: slab-out-of-bounds in ip6_datagram_recv_specific_ctl+0x19b3/0x1a20
      [   12.351035] Read of size 1 at addr ffff88006adbc208 by task test_ip6_datagr/1799
      
      Setting end_seq is actually no more necessary in tcp_filter as it gets
      initialized later on in tcp_vX_fill_cb.
      
      Cc: Eric Dumazet <edumazet@google.com>
      Fixes: eeea10b8 ("tcp: add tcp_v4_fill_cb()/tcp_v4_restore_cb()")
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Signed-off-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>
      fba43f49
    • Soheil Hassas Yeganeh's avatar
      tcp: do not report TCP_CM_INQ of 0 for closed connections · 8accd04e
      Soheil Hassas Yeganeh authored
      [ Upstream commit 6466e715 ]
      
      Returning 0 as inq to userspace indicates there is no more data to
      read, and the application needs to wait for EPOLLIN. For a connection
      that has received FIN from the remote peer, however, the application
      must continue reading until getting EOF (return value of 0
      from tcp_recvmsg) or an error, if edge-triggered epoll (EPOLLET) is
      being used. Otherwise, the application will never receive a new
      EPOLLIN, since there is no epoll edge after the FIN.
      
      Return 1 when there is no data left on the queue but the
      connection has received FIN, so that the applications continue
      reading.
      
      Fixes: b75eba76 (tcp: send in-queue bytes in cmsg upon read)
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8accd04e
    • Xin Long's avatar
      sctp: remove sched init from sctp_stream_init · 0e6b33fa
      Xin Long authored
      [ Upstream commit 2e990dfd ]
      
      syzbot reported a NULL-ptr deref caused by that sched->init() in
      sctp_stream_init() set stream->rr_next = NULL.
      
        kasan: GPF could be caused by NULL-ptr deref or user memory access
        RIP: 0010:sctp_sched_rr_dequeue+0xd3/0x170 net/sctp/stream_sched_rr.c:141
        Call Trace:
          sctp_outq_dequeue_data net/sctp/outqueue.c:90 [inline]
          sctp_outq_flush_data net/sctp/outqueue.c:1079 [inline]
          sctp_outq_flush+0xba2/0x2790 net/sctp/outqueue.c:1205
      
      All sched info is saved in sout->ext now, in sctp_stream_init()
      sctp_stream_alloc_out() will not change it, there's no need to
      call sched->init() again, since sctp_outq_init() has already
      done it.
      
      Fixes: 5bbbbe32 ("sctp: introduce stream scheduler foundations")
      Reported-by: syzbot+4c9934f20522c0efd657@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e6b33fa
    • David Howells's avatar
      rxrpc: Fix client call queueing, waiting for channel · c5952168
      David Howells authored
      [ Upstream commit 69ffaebb ]
      
      rxrpc_get_client_conn() adds a new call to the front of the waiting_calls
      queue if the connection it's going to use already exists.  This is bad as
      it allows calls to get starved out.
      
      Fix this by adding to the tail instead.
      
      Also change the other enqueue point in the same function to put it on the
      front (ie. when we have a new connection).  This makes the point that in
      the case of a new connection the new call goes at the front (though it
      doesn't actually matter since the queue should be unoccupied).
      
      Fixes: 45025bce ("rxrpc: Improve management and caching of client connection objects")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5952168
    • Xin Long's avatar
      route: set the deleted fnhe fnhe_daddr to 0 in ip_del_fnhe to fix a race · eaa0962e
      Xin Long authored
      [ Upstream commit ee60ad21 ]
      
      The race occurs in __mkroute_output() when 2 threads lookup a dst:
      
        CPU A                 CPU B
        find_exception()
                              find_exception() [fnhe expires]
                              ip_del_fnhe() [fnhe is deleted]
        rt_bind_exception()
      
      In rt_bind_exception() it will bind a deleted fnhe with the new dst, and
      this dst will get no chance to be freed. It causes a dev defcnt leak and
      consecutive dmesg warnings:
      
        unregister_netdevice: waiting for ethX to become free. Usage count = 1
      
      Especially thanks Jon to identify the issue.
      
      This patch fixes it by setting fnhe_daddr to 0 in ip_del_fnhe() to stop
      binding the deleted fnhe with a new dst when checking fnhe's fnhe_daddr
      and daddr in rt_bind_exception().
      
      It works as both ip_del_fnhe() and rt_bind_exception() are protected by
      fnhe_lock and the fhne is freed by kfree_rcu().
      
      Fixes: deed49df ("route: check and remove route cache when we get route")
      Signed-off-by: default avatarJon Maxwell <jmaxwell37@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eaa0962e
    • Masaru Nagai's avatar
      ravb: Decrease TxFIFO depth of Q3 and Q2 to one · ec61b953
      Masaru Nagai authored
      [ Upstream commit ae9819e3 ]
      
      Hardware has the CBS (Credit Based Shaper) which affects only Q3
      and Q2. When updating the CBS settings, even if the driver does so
      after waiting for Tx DMA finished, there is a possibility that frame
      data still remains in TxFIFO.
      
      To avoid this, decrease TxFIFO depth of Q3 and Q2 to one.
      
      This patch has been exercised this using netperf TCP_MAERTS, TCP_STREAM
      and UDP_STREAM tests run on an Ebisu board. No performance change was
      detected, outside of noise in the tests, both in terms of throughput and
      CPU utilisation.
      
      Fixes: c156633f ("Renesas Ethernet AVB driver proper")
      Signed-off-by: default avatarMasaru Nagai <masaru.nagai.vx@renesas.com>
      Signed-off-by: default avatarKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
      [simon: updated changelog]
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec61b953
    • Xin Long's avatar
      pptp: dst_release sk_dst_cache in pptp_sock_destruct · 34dc08b9
      Xin Long authored
      [ Upstream commit 9417d81f ]
      
      sk_setup_caps() is called to set sk->sk_dst_cache in pptp_connect,
      so we have to dst_release(sk->sk_dst_cache) in pptp_sock_destruct,
      otherwise, the dst refcnt will leak.
      
      It can be reproduced by this syz log:
      
        r1 = socket$pptp(0x18, 0x1, 0x2)
        bind$pptp(r1, &(0x7f0000000100)={0x18, 0x2, {0x0, @local}}, 0x1e)
        connect$pptp(r1, &(0x7f0000000000)={0x18, 0x2, {0x3, @remote}}, 0x1e)
      
      Consecutive dmesg warnings will occur:
      
        unregister_netdevice: waiting for lo to become free. Usage count = 1
      
      v1->v2:
        - use rcu_dereference_protected() instead of rcu_dereference_check(),
          as suggested by Eric.
      
      Fixes: 00959ade ("PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)")
      Reported-by: default avatarXiumei Mu <xmu@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34dc08b9
    • Eric Dumazet's avatar
      net/x25: reset state in x25_connect() · 14d5e73b
      Eric Dumazet authored
      [ Upstream commit ee74d0bd ]
      
      In case x25_connect() fails and frees the socket neighbour,
      we also need to undo the change done to x25->state.
      
      Before my last bug fix, we had use-after-free so this
      patch fixes a latent bug.
      
      syzbot report :
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 16137 Comm: syz-executor.1 Not tainted 5.0.0+ #117
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:x25_write_internal+0x1e8/0xdf0 net/x25/x25_subr.c:173
      Code: 00 40 88 b5 e0 fe ff ff 0f 85 01 0b 00 00 48 8b 8b 80 04 00 00 48 ba 00 00 00 00 00 fc ff df 48 8d 79 1c 48 89 fe 48 c1 ee 03 <0f> b6 34 16 48 89 fa 83 e2 07 83 c2 03 40 38 f2 7c 09 40 84 f6 0f
      RSP: 0018:ffff888076717a08 EFLAGS: 00010207
      RAX: ffff88805f2f2292 RBX: ffff8880a0ae6000 RCX: 0000000000000000
      kobject: 'loop5' (0000000018d0d0ee): kobject_uevent_env
      RDX: dffffc0000000000 RSI: 0000000000000003 RDI: 000000000000001c
      RBP: ffff888076717b40 R08: ffff8880950e0580 R09: ffffed100be5e46d
      R10: ffffed100be5e46c R11: ffff88805f2f2363 R12: ffff888065579840
      kobject: 'loop5' (0000000018d0d0ee): fill_kobj_path: path = '/devices/virtual/block/loop5'
      R13: 1ffff1100ece2f47 R14: 0000000000000013 R15: 0000000000000013
      FS:  00007fb88cf43700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f9a42a41028 CR3: 0000000087a67000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       x25_release+0xd0/0x340 net/x25/af_x25.c:658
       __sock_release+0xd3/0x2b0 net/socket.c:579
       sock_close+0x1b/0x30 net/socket.c:1162
       __fput+0x2df/0x8d0 fs/file_table.c:278
       ____fput+0x16/0x20 fs/file_table.c:309
       task_work_run+0x14a/0x1c0 kernel/task_work.c:113
       get_signal+0x1961/0x1d50 kernel/signal.c:2388
       do_signal+0x87/0x1940 arch/x86/kernel/signal.c:816
       exit_to_usermode_loop+0x244/0x2c0 arch/x86/entry/common.c:162
       prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
       do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457f29
      Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fb88cf42c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      RAX: fffffffffffffe00 RBX: 0000000000000003 RCX: 0000000000457f29
      RDX: 0000000000000012 RSI: 0000000020000080 RDI: 0000000000000004
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb88cf436d4
      R13: 00000000004be462 R14: 00000000004cec98 R15: 00000000ffffffff
      Modules linked in:
      
      Fixes: 95d6ebd5 ("net/x25: fix use-after-free in x25_device_event()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: andrew hendry <andrew.hendry@gmail.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14d5e73b
    • Eric Dumazet's avatar
      net/x25: fix use-after-free in x25_device_event() · b5c10907
      Eric Dumazet authored
      [ Upstream commit 95d6ebd5 ]
      
      In case of failure x25_connect() does a x25_neigh_put(x25->neighbour)
      but forgets to clear x25->neighbour pointer, thus triggering use-after-free.
      
      Since the socket is visible in x25_list, we need to hold x25_list_lock
      to protect the operation.
      
      syzbot report :
      
      BUG: KASAN: use-after-free in x25_kill_by_device net/x25/af_x25.c:217 [inline]
      BUG: KASAN: use-after-free in x25_device_event+0x296/0x2b0 net/x25/af_x25.c:252
      Read of size 8 at addr ffff8880a030edd0 by task syz-executor003/7854
      
      CPU: 0 PID: 7854 Comm: syz-executor003 Not tainted 5.0.0+ #97
      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+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
       x25_kill_by_device net/x25/af_x25.c:217 [inline]
       x25_device_event+0x296/0x2b0 net/x25/af_x25.c:252
       notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
       call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
       call_netdevice_notifiers net/core/dev.c:1765 [inline]
       __dev_notify_flags+0x1e9/0x2c0 net/core/dev.c:7607
       dev_change_flags+0x10d/0x170 net/core/dev.c:7643
       dev_ifsioc+0x2b0/0x940 net/core/dev_ioctl.c:237
       dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:488
       sock_do_ioctl+0x1bd/0x300 net/socket.c:995
       sock_ioctl+0x32b/0x610 net/socket.c:1096
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4467c9
      Code: e8 0c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 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 5b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fdbea222d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00000000006dbc58 RCX: 00000000004467c9
      RDX: 0000000020000340 RSI: 0000000000008914 RDI: 0000000000000003
      RBP: 00000000006dbc50 R08: 00007fdbea223700 R09: 0000000000000000
      R10: 00007fdbea223700 R11: 0000000000000246 R12: 00000000006dbc5c
      R13: 6000030030626669 R14: 0000000000000000 R15: 0000000030626669
      
      Allocated by task 7843:
       save_stack+0x45/0xd0 mm/kasan/common.c:73
       set_track mm/kasan/common.c:85 [inline]
       __kasan_kmalloc mm/kasan/common.c:495 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:468
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:509
       kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
       kmalloc include/linux/slab.h:545 [inline]
       x25_link_device_up+0x46/0x3f0 net/x25/x25_link.c:249
       x25_device_event+0x116/0x2b0 net/x25/af_x25.c:242
       notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
       call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
       call_netdevice_notifiers net/core/dev.c:1765 [inline]
       __dev_notify_flags+0x121/0x2c0 net/core/dev.c:7605
       dev_change_flags+0x10d/0x170 net/core/dev.c:7643
       dev_ifsioc+0x2b0/0x940 net/core/dev_ioctl.c:237
       dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:488
       sock_do_ioctl+0x1bd/0x300 net/socket.c:995
       sock_ioctl+0x32b/0x610 net/socket.c:1096
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 7865:
       save_stack+0x45/0xd0 mm/kasan/common.c:73
       set_track mm/kasan/common.c:85 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:457
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:465
       __cache_free mm/slab.c:3494 [inline]
       kfree+0xcf/0x230 mm/slab.c:3811
       x25_neigh_put include/net/x25.h:253 [inline]
       x25_connect+0x8d8/0xde0 net/x25/af_x25.c:824
       __sys_connect+0x266/0x330 net/socket.c:1685
       __do_sys_connect net/socket.c:1696 [inline]
       __se_sys_connect net/socket.c:1693 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1693
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8880a030edc0
       which belongs to the cache kmalloc-256 of size 256
      The buggy address is located 16 bytes inside of
       256-byte region [ffff8880a030edc0, ffff8880a030eec0)
      The buggy address belongs to the page:
      page:ffffea000280c380 count:1 mapcount:0 mapping:ffff88812c3f07c0 index:0x0
      flags: 0x1fffc0000000200(slab)
      raw: 01fffc0000000200 ffffea0002806788 ffffea00027f0188 ffff88812c3f07c0
      raw: 0000000000000000 ffff8880a030e000 000000010000000c 0000000000000000
      page dumped because: kasan: bad access detected
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: syzbot+04babcefcd396fabec37@syzkaller.appspotmail.com
      Cc: andrew hendry <andrew.hendry@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5c10907
    • Miaohe Lin's avatar
      net: sit: fix UBSAN Undefined behaviour in check_6rd · 7cfb97ba
      Miaohe Lin authored
      [ Upstream commit a843dc4e ]
      
      In func check_6rd,tunnel->ip6rd.relay_prefixlen may equal to
      32,so UBSAN complain about it.
      
      UBSAN: Undefined behaviour in net/ipv6/sit.c:781:47
      shift exponent 32 is too large for 32-bit type 'unsigned int'
      CPU: 6 PID: 20036 Comm: syz-executor.0 Not tainted 4.19.27 #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
      04/01/2014
      Call Trace:
      __dump_stack lib/dump_stack.c:77 [inline]
      dump_stack+0xca/0x13e lib/dump_stack.c:113
      ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
      __ubsan_handle_shift_out_of_bounds+0x293/0x2e8 lib/ubsan.c:425
      check_6rd.constprop.9+0x433/0x4e0 net/ipv6/sit.c:781
      try_6rd net/ipv6/sit.c:806 [inline]
      ipip6_tunnel_xmit net/ipv6/sit.c:866 [inline]
      sit_tunnel_xmit+0x141c/0x2720 net/ipv6/sit.c:1033
      __netdev_start_xmit include/linux/netdevice.h:4300 [inline]
      netdev_start_xmit include/linux/netdevice.h:4309 [inline]
      xmit_one net/core/dev.c:3243 [inline]
      dev_hard_start_xmit+0x17c/0x780 net/core/dev.c:3259
      __dev_queue_xmit+0x1656/0x2500 net/core/dev.c:3829
      neigh_output include/net/neighbour.h:501 [inline]
      ip6_finish_output2+0xa36/0x2290 net/ipv6/ip6_output.c:120
      ip6_finish_output+0x3e7/0xa20 net/ipv6/ip6_output.c:154
      NF_HOOK_COND include/linux/netfilter.h:278 [inline]
      ip6_output+0x1e2/0x720 net/ipv6/ip6_output.c:171
      dst_output include/net/dst.h:444 [inline]
      ip6_local_out+0x99/0x170 net/ipv6/output_core.c:176
      ip6_send_skb+0x9d/0x2f0 net/ipv6/ip6_output.c:1697
      ip6_push_pending_frames+0xc0/0x100 net/ipv6/ip6_output.c:1717
      rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
      rawv6_sendmsg+0x2435/0x3530 net/ipv6/raw.c:946
      inet_sendmsg+0xf8/0x5c0 net/ipv4/af_inet.c:798
      sock_sendmsg_nosec net/socket.c:621 [inline]
      sock_sendmsg+0xc8/0x110 net/socket.c:631
      ___sys_sendmsg+0x6cf/0x890 net/socket.c:2114
      __sys_sendmsg+0xf0/0x1b0 net/socket.c:2152
      do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Signed-off-by: default avatarlinmiaohe <linmiaohe@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cfb97ba
    • Eric Dumazet's avatar
      net/hsr: fix possible crash in add_timer() · 86a71f00
      Eric Dumazet authored
      [ Upstream commit 1e027960 ]
      
      syzbot found another add_timer() issue, this time in net/hsr [1]
      
      Let's use mod_timer() which is safe.
      
      [1]
      kernel BUG at kernel/time/timer.c:1136!
      invalid opcode: 0000 [#1] PREEMPT SMP KASAN
      CPU: 0 PID: 15909 Comm: syz-executor.3 Not tainted 5.0.0+ #97
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      kobject: 'loop2' (00000000f5629718): kobject_uevent_env
      RIP: 0010:add_timer kernel/time/timer.c:1136 [inline]
      RIP: 0010:add_timer+0x654/0xbe0 kernel/time/timer.c:1134
      Code: 0f 94 c5 31 ff 44 89 ee e8 09 61 0f 00 45 84 ed 0f 84 77 fd ff ff e8 bb 5f 0f 00 e8 07 10 a0 ff e9 68 fd ff ff e8 ac 5f 0f 00 <0f> 0b e8 a5 5f 0f 00 0f 0b e8 9e 5f 0f 00 4c 89 b5 58 ff ff ff e9
      RSP: 0018:ffff8880656eeca0 EFLAGS: 00010246
      kobject: 'loop2' (00000000f5629718): fill_kobj_path: path = '/devices/virtual/block/loop2'
      RAX: 0000000000040000 RBX: 1ffff1100caddd9a RCX: ffffc9000c436000
      RDX: 0000000000040000 RSI: ffffffff816056c4 RDI: ffff88806a2f6cc8
      RBP: ffff8880656eed58 R08: ffff888067f4a300 R09: ffff888067f4abc8
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff88806a2f6cc0
      R13: dffffc0000000000 R14: 0000000000000001 R15: ffff8880656eed30
      FS:  00007fc2019bf700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000738000 CR3: 0000000067e8e000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       hsr_check_announce net/hsr/hsr_device.c:99 [inline]
       hsr_check_carrier_and_operstate+0x567/0x6f0 net/hsr/hsr_device.c:120
       hsr_netdev_notify+0x297/0xa00 net/hsr/hsr_main.c:51
       notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
       call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
       call_netdevice_notifiers net/core/dev.c:1765 [inline]
       dev_open net/core/dev.c:1436 [inline]
       dev_open+0x143/0x160 net/core/dev.c:1424
       team_port_add drivers/net/team/team.c:1203 [inline]
       team_add_slave+0xa07/0x15d0 drivers/net/team/team.c:1933
       do_set_master net/core/rtnetlink.c:2358 [inline]
       do_set_master+0x1d4/0x230 net/core/rtnetlink.c:2332
       do_setlink+0x966/0x3510 net/core/rtnetlink.c:2493
       rtnl_setlink+0x271/0x3b0 net/core/rtnetlink.c:2747
       rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192
       netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485
       rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925
       sock_sendmsg_nosec net/socket.c:622 [inline]
       sock_sendmsg+0xdd/0x130 net/socket.c:632
       sock_write_iter+0x27c/0x3e0 net/socket.c:923
       call_write_iter include/linux/fs.h:1869 [inline]
       do_iter_readv_writev+0x5e0/0x8e0 fs/read_write.c:680
       do_iter_write fs/read_write.c:956 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:937
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1001
       do_writev+0xf6/0x290 fs/read_write.c:1036
       __do_sys_writev fs/read_write.c:1109 [inline]
       __se_sys_writev fs/read_write.c:1106 [inline]
       __x64_sys_writev+0x75/0xb0 fs/read_write.c:1106
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457f29
      Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fc2019bec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457f29
      RDX: 0000000000000001 RSI: 00000000200000c0 RDI: 0000000000000003
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc2019bf6d4
      R13: 00000000004c4a60 R14: 00000000004dd218 R15: 00000000ffffffff
      
      Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Arvid Brodin <arvid.brodin@alten.se>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86a71f00
    • Mao Wenan's avatar
      net: hsr: fix memory leak in hsr_dev_finalize() · 996ee1ac
      Mao Wenan authored
      [ Upstream commit 6caabe7f ]
      
      If hsr_add_port(hsr, hsr_dev, HSR_PT_MASTER) failed to
      add port, it directly returns res and forgets to free the node
      that allocated in hsr_create_self_node(), and forgets to delete
      the node->mac_list linked in hsr->self_node_db.
      
      BUG: memory leak
      unreferenced object 0xffff8881cfa0c780 (size 64):
        comm "syz-executor.0", pid 2077, jiffies 4294717969 (age 2415.377s)
        hex dump (first 32 bytes):
          e0 c7 a0 cf 81 88 ff ff 00 02 00 00 00 00 ad de  ................
          00 e6 49 cd 81 88 ff ff c0 9b 87 d0 81 88 ff ff  ..I.............
        backtrace:
          [<00000000e2ff5070>] hsr_dev_finalize+0x736/0x960 [hsr]
          [<000000003ed2e597>] hsr_newlink+0x2b2/0x3e0 [hsr]
          [<000000003fa8c6b6>] __rtnl_newlink+0xf1f/0x1600 net/core/rtnetlink.c:3182
          [<000000001247a7ad>] rtnl_newlink+0x66/0x90 net/core/rtnetlink.c:3240
          [<00000000e7d1b61d>] rtnetlink_rcv_msg+0x54e/0xb90 net/core/rtnetlink.c:5130
          [<000000005556bd3a>] netlink_rcv_skb+0x129/0x340 net/netlink/af_netlink.c:2477
          [<00000000741d5ee6>] netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
          [<00000000741d5ee6>] netlink_unicast+0x49a/0x650 net/netlink/af_netlink.c:1336
          [<000000009d56f9b7>] netlink_sendmsg+0x88b/0xdf0 net/netlink/af_netlink.c:1917
          [<0000000046b35c59>] sock_sendmsg_nosec net/socket.c:621 [inline]
          [<0000000046b35c59>] sock_sendmsg+0xc3/0x100 net/socket.c:631
          [<00000000d208adc9>] __sys_sendto+0x33e/0x560 net/socket.c:1786
          [<00000000b582837a>] __do_sys_sendto net/socket.c:1798 [inline]
          [<00000000b582837a>] __se_sys_sendto net/socket.c:1794 [inline]
          [<00000000b582837a>] __x64_sys_sendto+0xdd/0x1b0 net/socket.c:1794
          [<00000000c866801d>] do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
          [<00000000fea382d9>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
          [<00000000e01dacb3>] 0xffffffffffffffff
      
      Fixes: c5a75911 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      996ee1ac
    • Bryan Whitehead's avatar
      lan743x: Fix TX Stall Issue · ab13fe32
      Bryan Whitehead authored
      [ Upstream commit deb6bfab ]
      
      It has been observed that tx queue may stall while downloading
      from certain web sites (example www.speedtest.net)
      
      The cause has been tracked down to a corner case where
      the tx interrupt vector was disabled automatically, but
      was not re enabled later.
      
      The lan743x has two mechanisms to enable/disable individual
      interrupts. Interrupts can be enabled/disabled by individual
      source, and they can also be enabled/disabled by individual
      vector which has been mapped to the source. Both must be
      enabled for interrupts to work properly.
      
      The TX code path, primarily uses the interrupt enable/disable of
      the TX source bit, while leaving the vector enabled all the time.
      
      However, while investigating this issue it was noticed that
      the driver requested the use of the vector auto clear feature.
      
      The test above revealed a case where the vector enable was
      cleared unintentionally.
      
      This patch fixes the issue by deleting the lines that request
      the vector auto clear feature to be used.
      
      Fixes: 23f0703c ("lan743x: Add main source files for new lan743x driver")
      Signed-off-by: default avatarBryan Whitehead <Bryan.Whitehead@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab13fe32
    • Bryan Whitehead's avatar
      lan743x: Fix RX Kernel Panic · 22326473
      Bryan Whitehead authored
      [ Upstream commit dd9d9f59 ]
      
      It has been noticed that running the speed test at
      www.speedtest.net occasionally causes a kernel panic.
      
      Investigation revealed that under this test RX buffer allocation
      sometimes fails and returns NULL. But the lan743x driver did
      not handle this case.
      
      This patch fixes this issue by attempting to allocate a buffer
      before sending the new rx packet to the OS. If the allocation
      fails then the new rx packet is dropped and the existing buffer
      is reused in the DMA ring.
      
      Updates for v2:
          Additional 2 locations where allocation was not checked,
              has been changed to reuse existing buffer.
      
      Fixes: 23f0703c ("lan743x: Add main source files for new lan743x driver")
      Signed-off-by: default avatarBryan Whitehead <Bryan.Whitehead@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22326473
    • Eric Dumazet's avatar
      l2tp: fix infoleak in l2tp_ip6_recvmsg() · 96d58cd8
      Eric Dumazet authored
      [ Upstream commit 163d1c3d ]
      
      Back in 2013 Hannes took care of most of such leaks in commit
      bceaa902 ("inet: prevent leakage of uninitialized memory to user in recv syscalls")
      
      But the bug in l2tp_ip6_recvmsg() has not been fixed.
      
      syzbot report :
      
      BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
      CPU: 1 PID: 10996 Comm: syz-executor362 Not tainted 5.0.0+ #11
      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:600
       kmsan_internal_check_memory+0x9f4/0xb10 mm/kmsan/kmsan.c:694
       kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
       _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
       copy_to_user include/linux/uaccess.h:174 [inline]
       move_addr_to_user+0x311/0x570 net/socket.c:227
       ___sys_recvmsg+0xb65/0x1310 net/socket.c:2283
       do_recvmmsg+0x646/0x10c0 net/socket.c:2390
       __sys_recvmmsg net/socket.c:2469 [inline]
       __do_sys_recvmmsg net/socket.c:2492 [inline]
       __se_sys_recvmmsg+0x1d1/0x350 net/socket.c:2485
       __x64_sys_recvmmsg+0x62/0x80 net/socket.c:2485
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x445819
      Code: e8 6c b6 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f64453eddb8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
      RAX: ffffffffffffffda RBX: 00000000006dac28 RCX: 0000000000445819
      RDX: 0000000000000005 RSI: 0000000020002f80 RDI: 0000000000000003
      RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac2c
      R13: 00007ffeba8f87af R14: 00007f64453ee9c0 R15: 20c49ba5e353f7cf
      
      Local variable description: ----addr@___sys_recvmsg
      Variable was created at:
       ___sys_recvmsg+0xf6/0x1310 net/socket.c:2244
       do_recvmmsg+0x646/0x10c0 net/socket.c:2390
      
      Bytes 0-31 of 32 are uninitialized
      Memory access of size 32 starts at ffff8880ae62fbb0
      Data copied to user address 0000000020000000
      
      Fixes: a32e0eec ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96d58cd8
    • Paolo Abeni's avatar
      ipv4/route: fail early when inet dev is missing · 7760937d
      Paolo Abeni authored
      [ Upstream commit 22c74764 ]
      
      If a non local multicast packet reaches ip_route_input_rcu() while
      the ingress device IPv4 private data (in_dev) is NULL, we end up
      doing a NULL pointer dereference in IN_DEV_MFORWARD().
      
      Since the later call to ip_route_input_mc() is going to fail if
      !in_dev, we can fail early in such scenario and avoid the dangerous
      code path.
      
      v1 -> v2:
       - clarified the commit message, no code changes
      Reported-by: default avatarTianhao Zhao <tizhao@redhat.com>
      Fixes: e58e4159 ("net: Enable support for VRF with ipv4 multicast")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7760937d
    • Eric Dumazet's avatar
      gro_cells: make sure device is up in gro_cells_receive() · df737fd0
      Eric Dumazet authored
      [ Upstream commit 2a5ff07a ]
      
      We keep receiving syzbot reports [1] that show that tunnels do not play
      the rcu/IFF_UP rules properly.
      
      At device dismantle phase, gro_cells_destroy() will be called
      only after a full rcu grace period is observed after IFF_UP
      has been cleared.
      
      This means that IFF_UP needs to be tested before queueing packets
      into netif_rx() or gro_cells.
      
      This patch implements the test in gro_cells_receive() because
      too many callers do not seem to bother enough.
      
      [1]
      BUG: unable to handle kernel paging request at fffff4ca0b9ffffe
      PGD 0 P4D 0
      Oops: 0000 [#1] PREEMPT SMP KASAN
      CPU: 0 PID: 21 Comm: kworker/u4:1 Not tainted 5.0.0+ #97
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: netns cleanup_net
      RIP: 0010:__skb_unlink include/linux/skbuff.h:1929 [inline]
      RIP: 0010:__skb_dequeue include/linux/skbuff.h:1945 [inline]
      RIP: 0010:__skb_queue_purge include/linux/skbuff.h:2656 [inline]
      RIP: 0010:gro_cells_destroy net/core/gro_cells.c:89 [inline]
      RIP: 0010:gro_cells_destroy+0x19d/0x360 net/core/gro_cells.c:78
      Code: 03 42 80 3c 20 00 0f 85 53 01 00 00 48 8d 7a 08 49 8b 47 08 49 c7 07 00 00 00 00 48 89 f9 49 c7 47 08 00 00 00 00 48 c1 e9 03 <42> 80 3c 21 00 0f 85 10 01 00 00 48 89 c1 48 89 42 08 48 c1 e9 03
      RSP: 0018:ffff8880aa3f79a8 EFLAGS: 00010a02
      RAX: 00ffffffffffffe8 RBX: ffffe8ffffc64b70 RCX: 1ffff8ca0b9ffffe
      RDX: ffffc6505cffffe8 RSI: ffffffff858410ca RDI: ffffc6505cfffff0
      RBP: ffff8880aa3f7a08 R08: ffff8880aa3e8580 R09: fffffbfff1263645
      R10: fffffbfff1263644 R11: ffffffff8931b223 R12: dffffc0000000000
      R13: 0000000000000000 R14: ffffe8ffffc64b80 R15: ffffe8ffffc64b75
      kobject: 'loop2' (000000004bd7d84a): kobject_uevent_env
      FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: fffff4ca0b9ffffe CR3: 0000000094941000 CR4: 00000000001406f0
      Call Trace:
      kobject: 'loop2' (000000004bd7d84a): fill_kobj_path: path = '/devices/virtual/block/loop2'
       ip_tunnel_dev_free+0x19/0x60 net/ipv4/ip_tunnel.c:1010
       netdev_run_todo+0x51c/0x7d0 net/core/dev.c:8970
       rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:116
       ip_tunnel_delete_nets+0x423/0x5f0 net/ipv4/ip_tunnel.c:1124
       vti_exit_batch_net+0x23/0x30 net/ipv4/ip_vti.c:495
       ops_exit_list.isra.0+0x105/0x160 net/core/net_namespace.c:156
       cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551
       process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
       worker_thread+0x98/0xe40 kernel/workqueue.c:2319
       kthread+0x357/0x430 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      Modules linked in:
      CR2: fffff4ca0b9ffffe
         [ end trace 513fc9c1338d1cb3 ]
      RIP: 0010:__skb_unlink include/linux/skbuff.h:1929 [inline]
      RIP: 0010:__skb_dequeue include/linux/skbuff.h:1945 [inline]
      RIP: 0010:__skb_queue_purge include/linux/skbuff.h:2656 [inline]
      RIP: 0010:gro_cells_destroy net/core/gro_cells.c:89 [inline]
      RIP: 0010:gro_cells_destroy+0x19d/0x360 net/core/gro_cells.c:78
      Code: 03 42 80 3c 20 00 0f 85 53 01 00 00 48 8d 7a 08 49 8b 47 08 49 c7 07 00 00 00 00 48 89 f9 49 c7 47 08 00 00 00 00 48 c1 e9 03 <42> 80 3c 21 00 0f 85 10 01 00 00 48 89 c1 48 89 42 08 48 c1 e9 03
      RSP: 0018:ffff8880aa3f79a8 EFLAGS: 00010a02
      RAX: 00ffffffffffffe8 RBX: ffffe8ffffc64b70 RCX: 1ffff8ca0b9ffffe
      RDX: ffffc6505cffffe8 RSI: ffffffff858410ca RDI: ffffc6505cfffff0
      RBP: ffff8880aa3f7a08 R08: ffff8880aa3e8580 R09: fffffbfff1263645
      R10: fffffbfff1263644 R11: ffffffff8931b223 R12: dffffc0000000000
      kobject: 'loop3' (00000000e4ee57a6): kobject_uevent_env
      R13: 0000000000000000 R14: ffffe8ffffc64b80 R15: ffffe8ffffc64b75
      FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: fffff4ca0b9ffffe CR3: 0000000094941000 CR4: 00000000001406f0
      
      Fixes: c9e6bc64 ("net: add gro_cells infrastructure")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df737fd0
    • Li RongQing's avatar
      connector: fix unsafe usage of ->real_parent · ef9ef4ad
      Li RongQing authored
      [ Upstream commit 6d2b0f02 ]
      
      proc_exit_connector() uses ->real_parent lockless. This is not
      safe that its parent can go away at any moment, so use RCU to
      protect it, and ensure that this task is not released.
      
      [  747.624551] ==================================================================
      [  747.632946] BUG: KASAN: use-after-free in proc_exit_connector+0x1f7/0x310
      [  747.640686] Read of size 4 at addr ffff88a0276988e0 by task sshd/2882
      [  747.648032]
      [  747.649804] CPU: 11 PID: 2882 Comm: sshd Tainted: G            E     4.19.26-rc2 #11
      [  747.658629] Hardware name: IBM x3550M4 -[7914OFV]-/00AM544, BIOS -[D7E142BUS-1.71]- 07/31/2014
      [  747.668419] Call Trace:
      [  747.671269]  dump_stack+0xf0/0x19b
      [  747.675186]  ? show_regs_print_info+0x5/0x5
      [  747.679988]  ? kmsg_dump_rewind_nolock+0x59/0x59
      [  747.685302]  print_address_description+0x6a/0x270
      [  747.691162]  kasan_report+0x258/0x380
      [  747.695835]  ? proc_exit_connector+0x1f7/0x310
      [  747.701402]  proc_exit_connector+0x1f7/0x310
      [  747.706767]  ? proc_coredump_connector+0x2d0/0x2d0
      [  747.712715]  ? _raw_write_unlock_irq+0x29/0x50
      [  747.718270]  ? _raw_write_unlock_irq+0x29/0x50
      [  747.723820]  ? ___preempt_schedule+0x16/0x18
      [  747.729193]  ? ___preempt_schedule+0x16/0x18
      [  747.734574]  do_exit+0xa11/0x14f0
      [  747.738880]  ? mm_update_next_owner+0x590/0x590
      [  747.744525]  ? debug_show_all_locks+0x3c0/0x3c0
      [  747.761448]  ? ktime_get_coarse_real_ts64+0xeb/0x1c0
      [  747.767589]  ? lockdep_hardirqs_on+0x1a6/0x290
      [  747.773154]  ? check_chain_key+0x139/0x1f0
      [  747.778345]  ? check_flags.part.35+0x240/0x240
      [  747.783908]  ? __lock_acquire+0x2300/0x2300
      [  747.789171]  ? _raw_spin_unlock_irqrestore+0x59/0x70
      [  747.795316]  ? _raw_spin_unlock_irqrestore+0x59/0x70
      [  747.801457]  ? do_raw_spin_unlock+0x10f/0x1e0
      [  747.806914]  ? do_raw_spin_trylock+0x120/0x120
      [  747.812481]  ? preempt_count_sub+0x14/0xc0
      [  747.817645]  ? _raw_spin_unlock+0x2e/0x50
      [  747.822708]  ? __handle_mm_fault+0x12db/0x1fa0
      [  747.828367]  ? __pmd_alloc+0x2d0/0x2d0
      [  747.833143]  ? check_noncircular+0x50/0x50
      [  747.838309]  ? match_held_lock+0x7f/0x340
      [  747.843380]  ? check_noncircular+0x50/0x50
      [  747.848561]  ? handle_mm_fault+0x21a/0x5f0
      [  747.853730]  ? check_flags.part.35+0x240/0x240
      [  747.859290]  ? check_chain_key+0x139/0x1f0
      [  747.864474]  ? __do_page_fault+0x40f/0x760
      [  747.869655]  ? __audit_syscall_entry+0x4b/0x1f0
      [  747.875319]  ? syscall_trace_enter+0x1d5/0x7b0
      [  747.880877]  ? trace_raw_output_preemptirq_template+0x90/0x90
      [  747.887895]  ? trace_raw_output_sys_exit+0x80/0x80
      [  747.893860]  ? up_read+0x3b/0x90
      [  747.898142]  ? stop_critical_timings+0x260/0x260
      [  747.903909]  do_group_exit+0xe0/0x1c0
      [  747.908591]  ? __x64_sys_exit+0x30/0x30
      [  747.913460]  ? trace_raw_output_preemptirq_template+0x90/0x90
      [  747.920485]  ? tracer_hardirqs_on+0x270/0x270
      [  747.925956]  __x64_sys_exit_group+0x28/0x30
      [  747.931214]  do_syscall_64+0x117/0x400
      [  747.935988]  ? syscall_return_slowpath+0x2f0/0x2f0
      [  747.941931]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [  747.947788]  ? trace_hardirqs_on_caller+0x1d0/0x1d0
      [  747.953838]  ? lockdep_sys_exit+0x16/0x8e
      [  747.958915]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [  747.964784]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  747.971021] RIP: 0033:0x7f572f154c68
      [  747.975606] Code: Bad RIP value.
      [  747.979791] RSP: 002b:00007ffed2dfaa58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
      [  747.989324] RAX: ffffffffffffffda RBX: 00007f572f431840 RCX: 00007f572f154c68
      [  747.997910] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
      [  748.006495] RBP: 0000000000000001 R08: 00000000000000e7 R09: fffffffffffffee0
      [  748.015079] R10: 00007f572f4387e8 R11: 0000000000000246 R12: 00007f572f431840
      [  748.023664] R13: 000055a7f90f2c50 R14: 000055a7f96e2310 R15: 000055a7f96e2310
      [  748.032287]
      [  748.034509] Allocated by task 2300:
      [  748.038982]  kasan_kmalloc+0xa0/0xd0
      [  748.043562]  kmem_cache_alloc_node+0xf5/0x2e0
      [  748.049018]  copy_process+0x1781/0x4790
      [  748.053884]  _do_fork+0x166/0x9a0
      [  748.058163]  do_syscall_64+0x117/0x400
      [  748.062943]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  748.069180]
      [  748.071405] Freed by task 15395:
      [  748.075591]  __kasan_slab_free+0x130/0x180
      [  748.080752]  kmem_cache_free+0xc2/0x310
      [  748.085619]  free_task+0xea/0x130
      [  748.089901]  __put_task_struct+0x177/0x230
      [  748.095063]  finish_task_switch+0x51b/0x5d0
      [  748.100315]  __schedule+0x506/0xfa0
      [  748.104791]  schedule+0xca/0x260
      [  748.108978]  futex_wait_queue_me+0x27e/0x420
      [  748.114333]  futex_wait+0x251/0x550
      [  748.118814]  do_futex+0x75b/0xf80
      [  748.123097]  __x64_sys_futex+0x231/0x2a0
      [  748.128065]  do_syscall_64+0x117/0x400
      [  748.132835]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  748.139066]
      [  748.141289] The buggy address belongs to the object at ffff88a027698000
      [  748.141289]  which belongs to the cache task_struct of size 12160
      [  748.156589] The buggy address is located 2272 bytes inside of
      [  748.156589]  12160-byte region [ffff88a027698000, ffff88a02769af80)
      [  748.171114] The buggy address belongs to the page:
      [  748.177055] page:ffffea00809da600 count:1 mapcount:0 mapping:ffff888107d01e00 index:0x0 compound_mapcount: 0
      [  748.189136] flags: 0x57ffffc0008100(slab|head)
      [  748.194688] raw: 0057ffffc0008100 ffffea00809a3200 0000000300000003 ffff888107d01e00
      [  748.204424] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000
      [  748.214146] page dumped because: kasan: bad access detected
      [  748.220976]
      [  748.223197] Memory state around the buggy address:
      [  748.229128]  ffff88a027698780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.238271]  ffff88a027698800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.247414] >ffff88a027698880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.256564]                                                        ^
      [  748.264267]  ffff88a027698900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.273493]  ffff88a027698980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  748.282630] ==================================================================
      
      Fixes: b086ff87 ("connector: add parent pid and tgid to coredump and exit events")
      Signed-off-by: default avatarZhang Yu <zhangyu31@baidu.com>
      Signed-off-by: default avatarLi RongQing <lirongqing@baidu.com>
      Acked-by: default avatarEvgeniy Polyakov <zbr@ioremap.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef9ef4ad
  2. 13 Mar, 2019 17 commits