mptcp: handle mptcp listener destruction via rcu
authorFlorian Westphal <fw@strlen.de>
Mon, 20 Apr 2020 14:25:04 +0000 (16:25 +0200)
committerDavid S. Miller <davem@davemloft.net>
Mon, 20 Apr 2020 19:59:32 +0000 (12:59 -0700)
commit5e20087d1b678965ae9df01eed03efedc1aef9f8
tree1f015fb82ba6d3be8ee01a146fd0698992c4bb2d
parentbd019427bf3623ee3c7d2845cf921bbf4c14846c
mptcp: handle mptcp listener destruction via rcu

Following splat can occur during self test:

 BUG: KASAN: use-after-free in subflow_data_ready+0x156/0x160
 Read of size 8 at addr ffff888100c35c28 by task mptcp_connect/4808

  subflow_data_ready+0x156/0x160
  tcp_child_process+0x6a3/0xb30
  tcp_v4_rcv+0x2231/0x3730
  ip_protocol_deliver_rcu+0x5c/0x860
  ip_local_deliver_finish+0x220/0x360
  ip_local_deliver+0x1c8/0x4e0
  ip_rcv_finish+0x1da/0x2f0
  ip_rcv+0xd0/0x3c0
  __netif_receive_skb_one_core+0xf5/0x160
  __netif_receive_skb+0x27/0x1c0
  process_backlog+0x21e/0x780
  net_rx_action+0x35f/0xe90
  do_softirq+0x4c/0x50
  [..]

This occurs when accessing subflow_ctx->conn.

Problem is that tcp_child_process() calls listen sockets'
sk_data_ready() notification, but it doesn't hold the listener
lock.  Another cpu calling close() on the listener will then cause
transition of refcount to 0.

Fixes: 58b09919626bf ("mptcp: create msk early")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/mptcp/protocol.c