Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1936914ybi; Thu, 4 Jul 2019 02:21:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqyZfNJB8H3OHdrXifoBk1Yc7+FAVqFXMQRXr9v+vuoxwJLn5Bm9GupH1dN/Shdi1A0nJkpP X-Received: by 2002:a65:4844:: with SMTP id i4mr25799602pgs.113.1562232097701; Thu, 04 Jul 2019 02:21:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562232097; cv=none; d=google.com; s=arc-20160816; b=d8miA9q+vURnBbJyOqWM/qWyRd0zDJLC5YPpr3lsXrosugX6hpw0d/yJ01VVC8Wb7e lSUVSV0fwt08H/WuUZ3k7mXyHVdwBEeVDWWCs0wq5LNYUuRvK8e/mRE8Rbj5LcUAM63A nrmtDa9Ix6vRWc+DkIwd4mZXMz+2jvVvFOMSx7Ff0KUWZYlQLBe4CPFtr7M0oqPPHlWj d7/3KNu8tj+We16BuMjxM7Xf5gLX5BW9ZW9oPhf9/R8J8gOCZqTyJ0n6j4JDQrStuLgw duvR2Zfw9zTax5TDh3nACIlYbfz/Yd3rYfHPR6dUKGINc0Tj/t+GDvax3tqJrMjMFToE mWEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=f1r99RR7Q+xI/HzT6VXzcxAxrKbEaF2CKUPs7/mZplQ=; b=upG+q5MQzyFja99Vw6ELfm2mCiAG34D7jA3K4k+udfJABZRuM0cNvb6zdI2yBMeAHz Ki5xR8VrEkmwFWhwqE+sxXCwuwq8FKuLVsKwIMtMWf9ZycP6acThJRNjWvYMdGk1r4el FELvUs5p5bJzU8lha9TD7XuZGkGEma+/e0K+LPrQrfksURaoyk7MbUtHe1f88fCzzPGU YVeGm5ToIA5dyiCyppAcD31sULGImi2reINXyHZk+4b8on7Cchuwyc9UyLlk53gh3/ow JiSuF8YQxnkv+U9wvke8jkGur77KLQplr9DO54YcVLCIBwQ8GylHQmMFAr3ZqRRzhBER L4Xw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b61si4898082plb.401.2019.07.04.02.21.21; Thu, 04 Jul 2019 02:21:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727267AbfGDJUv (ORCPT + 99 others); Thu, 4 Jul 2019 05:20:51 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:35763 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727208AbfGDJUu (ORCPT ); Thu, 4 Jul 2019 05:20:50 -0400 Received: by mail-wr1-f68.google.com with SMTP id c27so5834890wrb.2 for ; Thu, 04 Jul 2019 02:20:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=f1r99RR7Q+xI/HzT6VXzcxAxrKbEaF2CKUPs7/mZplQ=; b=gxG9fcZa9Fwab/H/Yngz/uSf4duIhGmREcYWhqBOH5aK1UEP2Sm9ZvQG9pYG7EcdHJ saOhI/wISp/DtErNKDa/hUw1LDsICVdmNJbP8gm9ceLogJFDP4CsMngFo+UBIaxd25zW slxiNJTZofyIL1tgrv9k75+z+B6s9igq/1rrI3+fy87fLlembD7860vqovZa4Xv57T9i 6cTKOpNN2oF5TfbVJFeVgYGmOwY+XokEw6PTBDkEDyD+nhakQNtqRV3O7Fr1mG8h18Ab 3okZxruIb8CfzHa0I1k6Cmnlf9a5pmU6wl9JVt1l7KPtaN3MZO1NUAD/iJYlSumk4m1a 06mQ== X-Gm-Message-State: APjAAAXqHGXIFf+jl7xYhBsnGg/dLfTr1NGpEecpE595WhX5FGg5s3zC xPXOuGuiCyMgNXV2rqYLSwQsKQ== X-Received: by 2002:adf:b64b:: with SMTP id i11mr33084792wre.205.1562232047694; Thu, 04 Jul 2019 02:20:47 -0700 (PDT) Received: from steredhat.homenet.telecomitalia.it (host21-207-dynamic.52-79-r.retail.telecomitalia.it. [79.52.207.21]) by smtp.gmail.com with ESMTPSA id z25sm4919093wmf.38.2019.07.04.02.20.46 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 04 Jul 2019 02:20:47 -0700 (PDT) Date: Thu, 4 Jul 2019 11:20:44 +0200 From: Stefano Garzarella To: Jason Wang Cc: Stefan Hajnoczi , netdev@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, "Michael S. Tsirkin" , "David S. Miller" , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock Message-ID: <20190704092044.23gd5o2rhqarisgg@steredhat.homenet.telecomitalia.it> References: <20190628123659.139576-1-sgarzare@redhat.com> <20190628123659.139576-2-sgarzare@redhat.com> <05311244-ed23-d061-a620-7b83d83c11f5@redhat.com> <20190703104135.wg34dobv64k7u4jo@steredhat> <07e5bc00-ebde-4dac-d38c-f008fa230b5f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <07e5bc00-ebde-4dac-d38c-f008fa230b5f@redhat.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 04, 2019 at 11:58:00AM +0800, Jason Wang wrote: > > On 2019/7/3 下午6:41, Stefano Garzarella wrote: > > On Wed, Jul 03, 2019 at 05:53:58PM +0800, Jason Wang wrote: > > > On 2019/6/28 下午8:36, Stefano Garzarella wrote: > > > > Some callbacks used by the upper layers can run while we are in the > > > > .remove(). A potential use-after-free can happen, because we free > > > > the_virtio_vsock without knowing if the callbacks are over or not. > > > > > > > > To solve this issue we move the assignment of the_virtio_vsock at the > > > > end of .probe(), when we finished all the initialization, and at the > > > > beginning of .remove(), before to release resources. > > > > For the same reason, we do the same also for the vdev->priv. > > > > > > > > We use RCU to be sure that all callbacks that use the_virtio_vsock > > > > ended before freeing it. This is not required for callbacks that > > > > use vdev->priv, because after the vdev->config->del_vqs() we are sure > > > > that they are ended and will no longer be invoked. > > > > > > > > We also take the mutex during the .remove() to avoid that .probe() can > > > > run while we are resetting the device. > > > > > > > > Signed-off-by: Stefano Garzarella > > > > --- > > > > net/vmw_vsock/virtio_transport.c | 67 +++++++++++++++++++++----------- > > > > 1 file changed, 44 insertions(+), 23 deletions(-) > > > > > > > > diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c > > > > index 9c287e3e393c..7ad510ec12e0 100644 > > > > --- a/net/vmw_vsock/virtio_transport.c > > > > +++ b/net/vmw_vsock/virtio_transport.c > > > > @@ -65,19 +65,22 @@ struct virtio_vsock { > > > > u32 guest_cid; > > > > }; > > > > -static struct virtio_vsock *virtio_vsock_get(void) > > > > -{ > > > > - return the_virtio_vsock; > > > > -} > > > > - > > > > static u32 virtio_transport_get_local_cid(void) > > > > { > > > > - struct virtio_vsock *vsock = virtio_vsock_get(); > > > > + struct virtio_vsock *vsock; > > > > + u32 ret; > > > > - if (!vsock) > > > > - return VMADDR_CID_ANY; > > > > + rcu_read_lock(); > > > > + vsock = rcu_dereference(the_virtio_vsock); > > > > + if (!vsock) { > > > > + ret = VMADDR_CID_ANY; > > > > + goto out_rcu; > > > > + } > > > > - return vsock->guest_cid; > > > > + ret = vsock->guest_cid; > > > > +out_rcu: > > > > + rcu_read_unlock(); > > > > + return ret; > > > > } > > > > static void virtio_transport_loopback_work(struct work_struct *work) > > > > @@ -197,14 +200,18 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) > > > > struct virtio_vsock *vsock; > > > > int len = pkt->len; > > > > - vsock = virtio_vsock_get(); > > > > + rcu_read_lock(); > > > > + vsock = rcu_dereference(the_virtio_vsock); > > > > if (!vsock) { > > > > virtio_transport_free_pkt(pkt); > > > > - return -ENODEV; > > > > + len = -ENODEV; > > > > + goto out_rcu; > > > > } > > > > - if (le64_to_cpu(pkt->hdr.dst_cid) == vsock->guest_cid) > > > > - return virtio_transport_send_pkt_loopback(vsock, pkt); > > > > + if (le64_to_cpu(pkt->hdr.dst_cid) == vsock->guest_cid) { > > > > + len = virtio_transport_send_pkt_loopback(vsock, pkt); > > > > + goto out_rcu; > > > > + } > > > > if (pkt->reply) > > > > atomic_inc(&vsock->queued_replies); > > > > @@ -214,6 +221,9 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) > > > > spin_unlock_bh(&vsock->send_pkt_list_lock); > > > > queue_work(virtio_vsock_workqueue, &vsock->send_pkt_work); > > > > + > > > > +out_rcu: > > > > + rcu_read_unlock(); > > > > return len; > > > > } > > > > @@ -222,12 +232,14 @@ virtio_transport_cancel_pkt(struct vsock_sock *vsk) > > > > { > > > > struct virtio_vsock *vsock; > > > > struct virtio_vsock_pkt *pkt, *n; > > > > - int cnt = 0; > > > > + int cnt = 0, ret; > > > > LIST_HEAD(freeme); > > > > - vsock = virtio_vsock_get(); > > > > + rcu_read_lock(); > > > > + vsock = rcu_dereference(the_virtio_vsock); > > > > if (!vsock) { > > > > - return -ENODEV; > > > > + ret = -ENODEV; > > > > + goto out_rcu; > > > > } > > > > spin_lock_bh(&vsock->send_pkt_list_lock); > > > > @@ -255,7 +267,11 @@ virtio_transport_cancel_pkt(struct vsock_sock *vsk) > > > > queue_work(virtio_vsock_workqueue, &vsock->rx_work); > > > > } > > > > - return 0; > > > > + ret = 0; > > > > + > > > > +out_rcu: > > > > + rcu_read_unlock(); > > > > + return ret; > > > > } > > > > static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) > > > > @@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) > > > > vsock->rx_buf_max_nr = 0; > > > > atomic_set(&vsock->queued_replies, 0); > > > > - vdev->priv = vsock; > > > > - the_virtio_vsock = vsock; > > > > mutex_init(&vsock->tx_lock); > > > > mutex_init(&vsock->rx_lock); > > > > mutex_init(&vsock->event_lock); > > > > @@ -613,6 +627,9 @@ static int virtio_vsock_probe(struct virtio_device *vdev) > > > > virtio_vsock_event_fill(vsock); > > > > mutex_unlock(&vsock->event_lock); > > > > + vdev->priv = vsock; > > > > + rcu_assign_pointer(the_virtio_vsock, vsock); > > > > > > You probably need to use rcu_dereference_protected() to access > > > the_virtio_vsock in the function in order to survive from sparse. > > > > > Ooo, thanks! > > > > Do you mean when we check if the_virtio_vsock is not null at the beginning of > > virtio_vsock_probe()? > > > I mean instead of: > >     /* Only one virtio-vsock device per guest is supported */ >     if (the_virtio_vsock) { >         ret = -EBUSY; >         goto out; >     } > > you should use: > > if (rcu_dereference_protected(the_virtio_vosck, > lock_dep_is_held(&the_virtio_vsock_mutex)) > > ... Okay, thanks for confirming! I'll send a v3 to fix this! > > > > > > > > + > > > > mutex_unlock(&the_virtio_vsock_mutex); > > > > return 0; > > > > @@ -627,6 +644,12 @@ static void virtio_vsock_remove(struct virtio_device *vdev) > > > > struct virtio_vsock *vsock = vdev->priv; > > > > struct virtio_vsock_pkt *pkt; > > > > + mutex_lock(&the_virtio_vsock_mutex); > > > > + > > > > + vdev->priv = NULL; > > > > + rcu_assign_pointer(the_virtio_vsock, NULL); > > > > > > This is still suspicious, can we access the_virtio_vsock through vdev->priv? > > > If yes, we may still get use-after-free since it was not protected by RCU. > > We will free the object only after calling the del_vqs(), so we are sure > > that the vq_callbacks ended and will no longer be invoked. > > So, IIUC it shouldn't happen. > > > Yes, but any dereference that is not done in vq_callbacks will be very > dangerous in the future. Right. Do you think make sense to continue with this series in order to fix the hot-unplug issue, then I'll work to refactor the driver code to use the refcnt (as you suggested in patch 2) and singleton for the_virtio_vsock? Thanks, Stefano