search for: the_virtio_vsock

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 s...

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 s...

...rote: > 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. >&...

...rote: > 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. >&...

...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(), befor...

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-&g...

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 th...

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-&g...

This patch protects the reading of 'the_virtio_vsock' taking the mutex used when it is set. We also move the 'the_virtio_vsock' assignment at the end of the .probe(), when we finished all the initialization, and at the beginning of .remove(), before to release resources, taking the lock until the end of the function. Signed-off-by: Stefa...

Commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock' pointer, but we forgot to annotate it. This patch adds the annotation to fix the following sparse errors: net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison expression (different address spaces): n...

Commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock' pointer, but we forgot to annotate it. This patch adds the annotation to fix the following sparse errors: net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison expression (different address spaces): n...

On Fri, Jul 10, 2020 at 02:12:43PM +0200, Stefano Garzarella wrote: > Commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free > on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock' > pointer, but we forgot to annotate it. > > This patch adds the annotation to fix the following sparse errors: > > net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison expression (differe...

...sock/virtio: Initialize core virtio vsock before registering the driver", Stefan pointed out some possible issues in the .probe() and .remove() callbacks of the virtio-vsock driver. This series tries to solve these issues: - Patch 1 adds RCU critical sections to avoid use-after-free of 'the_virtio_vsock' pointer. - Patch 2 stops workers before to call vdev->config->reset(vdev) to be sure that no one is accessing the device. - Patch 3 moves the works flush at the end of the .remove() to avoid use-after-free of 'vsock' object. v2: - Patch 1: use RCU to protect 'the_virtio_...

...sock/virtio: Initialize core virtio vsock before registering the driver", Stefan pointed out some possible issues in the .probe() and .remove() callbacks of the virtio-vsock driver. This series tries to solve these issues: - Patch 1 adds RCU critical sections to avoid use-after-free of 'the_virtio_vsock' pointer. - Patch 2 stops workers before to call vdev->config->reset(vdev) to be sure that no one is accessing the device. - Patch 3 moves the works flush at the end of the .remove() to avoid use-after-free of 'vsock' object. v2: - Patch 1: use RCU to protect 'the_virtio_...

From: Stefano Garzarella <sgarzare at redhat.com> Date: Tue, 28 May 2019 12:56:20 +0200 > @@ -68,7 +68,13 @@ struct virtio_vsock { > > static struct virtio_vsock *virtio_vsock_get(void) > { > - return the_virtio_vsock; > + struct virtio_vsock *vsock; > + > + mutex_lock(&the_virtio_vsock_mutex); > + vsock = the_virtio_vsock; > + mutex_unlock(&the_virtio_vsock_mutex); > + > + return vsock; This doesn't do anything as far as I can tell. No matter what, you will either get the valu...

During the review of "[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver", Stefan pointed out some possible issues in the .probe() and .remove() callbacks of the virtio-vsock driver. This series tries to solve these issues: - Patch 1 postpones the 'the_virtio_vsock' assignment at the end of the .probe() to avoid that some sockets queue works when the initialization is not finished. - Patches 2 and 3 stop workers before to call vdev->config->reset(vdev) to be sure that no one is accessing the device, and adds another flush at the end of the ....

During the review of "[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver", Stefan pointed out some possible issues in the .probe() and .remove() callbacks of the virtio-vsock driver. This series tries to solve these issues: - Patch 1 postpones the 'the_virtio_vsock' assignment at the end of the .probe() to avoid that some sockets queue works when the initialization is not finished. - Patches 2 and 3 stop workers before to call vdev->config->reset(vdev) to be sure that no one is accessing the device, and adds another flush at the end of the ....

...sock/virtio: Initialize core virtio vsock before registering the driver", Stefan pointed out some possible issues in the .probe() and .remove() callbacks of the virtio-vsock driver. This series tries to solve these issues: - Patch 1 adds RCU critical sections to avoid use-after-free of 'the_virtio_vsock' pointer. - Patch 2 stops workers before to call vdev->config->reset(vdev) to be sure that no one is accessing the device. - Patch 3 moves the works flush at the end of the .remove() to avoid use-after-free of 'vsock' object. v3: - Patch 1: use rcu_dereference_protected() to...

...tatic void virtio_vsock_remove(struct virtio_device *vdev) >>>>> { >>>>> struct virtio_vsock *vsock = vdev->priv; >>>>> @@ -668,12 +677,6 @@ static void virtio_vsock_remove(struct virtio_device *vdev) >>>>> mutex_lock(&the_virtio_vsock_mutex); >>>>> the_virtio_vsock = NULL; >>>>> - flush_work(&vsock->loopback_work); >>>>> - flush_work(&vsock->rx_work); >>>>> - flush_work(&vsock->tx_work); >>>>> - flush_work(&vsock->event_wo...

...tatic void virtio_vsock_remove(struct virtio_device *vdev) >>>>> { >>>>> struct virtio_vsock *vsock = vdev->priv; >>>>> @@ -668,12 +677,6 @@ static void virtio_vsock_remove(struct virtio_device *vdev) >>>>> mutex_lock(&the_virtio_vsock_mutex); >>>>> the_virtio_vsock = NULL; >>>>> - flush_work(&vsock->loopback_work); >>>>> - flush_work(&vsock->rx_work); >>>>> - flush_work(&vsock->tx_work); >>>>> - flush_work(&vsock->event_wo...