[PATCH net] vsock: fix locking in vsock_shutdown()

[PATCH net] vsock: fix locking in vsock_shutdown()

[Stefano Garzarella]

In vsock_shutdown() we touched some socket fields without holding the
socket lock, such as 'state' and 'sk_flags'.

Also, after the introduction of multi-transport, we are accessing
'vsk->transport' in vsock_send_shutdown() without holding the lock
and this call can be made while the connection is in progress, so
the transport can change in the meantime.

To avoid issues, we hold the socket lock when we enter in
vsock_shutdown() and release it when we leave.

Among the transports that implement the 'shutdown' callback, only
hyperv_transport acquired the lock. Since the caller now holds it,
we no longer take it.

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 net/vmw_vsock/af_vsock.c         | 8 +++++---
 net/vmw_vsock/hyperv_transport.c | 2 --
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 4ea301fc2bf0..5546710d8ac1 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -943,10 +943,12 @@ static int vsock_shutdown(struct socket *sock, int mode)
 	 */
 
 	sk = sock->sk;
+
+	lock_sock(sk);
 	if (sock->state == SS_UNCONNECTED) {
 		err = -ENOTCONN;
 		if (sk->sk_type == SOCK_STREAM)
-			return err;
+			goto out;
 	} else {
 		sock->state = SS_DISCONNECTING;
 		err = 0;
@@ -955,10 +957,8 @@ static int vsock_shutdown(struct socket *sock, int mode)
 	/* Receive and send shutdowns are treated alike. */
 	mode = mode & (RCV_SHUTDOWN | SEND_SHUTDOWN);
 	if (mode) {
-		lock_sock(sk);
 		sk->sk_shutdown |= mode;
 		sk->sk_state_change(sk);
-		release_sock(sk);
 
 		if (sk->sk_type == SOCK_STREAM) {
 			sock_reset_flag(sk, SOCK_DONE);
@@ -966,6 +966,8 @@ static int vsock_shutdown(struct socket *sock, int mode)
 		}
 	}
 
+out:
+	release_sock(sk);
 	return err;
 }
 
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 630b851f8150..5a3beef73461 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -479,9 +479,7 @@ static int hvs_shutdown(struct vsock_sock *vsk, int mode)
 	if (!(mode & SEND_SHUTDOWN))
 		return 0;
 
-	lock_sock(sk);
 	hvs_shutdown_lock_held(vsk->trans, mode);
-	release_sock(sk);
 	return 0;
 }
 
-- 
2.29.2

Re: [PATCH net] vsock: fix locking in vsock_shutdown()

[Stefano Garzarella]

On Mon, Feb 08, 2021 at 03:43:07PM +0100, Stefano Garzarella wrote:
>In vsock_shutdown() we touched some socket fields without holding the
>socket lock, such as 'state' and 'sk_flags'.
>
>Also, after the introduction of multi-transport, we are accessing
>'vsk->transport' in vsock_send_shutdown() without holding the lock
>and this call can be made while the connection is in progress, so
>the transport can change in the meantime.
>
>To avoid issues, we hold the socket lock when we enter in
>vsock_shutdown() and release it when we leave.
>
>Among the transports that implement the 'shutdown' callback, only
>hyperv_transport acquired the lock. Since the caller now holds it,
>we no longer take it.
>
>Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
>Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>---
> net/vmw_vsock/af_vsock.c         | 8 +++++---
> net/vmw_vsock/hyperv_transport.c | 2 --
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index 4ea301fc2bf0..5546710d8ac1 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -943,10 +943,12 @@ static int vsock_shutdown(struct socket *sock, int mode)
> 	 */
>
> 	sk = sock->sk;
>+
>+	lock_sock(sk);
> 	if (sock->state == SS_UNCONNECTED) {
> 		err = -ENOTCONN;
> 		if (sk->sk_type == SOCK_STREAM)
>-			return err;
>+			goto out;
> 	} else {
> 		sock->state = SS_DISCONNECTING;
> 		err = 0;
>@@ -955,10 +957,8 @@ static int vsock_shutdown(struct socket *sock, int mode)
> 	/* Receive and send shutdowns are treated alike. */
> 	mode = mode & (RCV_SHUTDOWN | SEND_SHUTDOWN);
> 	if (mode) {
>-		lock_sock(sk);
> 		sk->sk_shutdown |= mode;
> 		sk->sk_state_change(sk);
>-		release_sock(sk);
>
> 		if (sk->sk_type == SOCK_STREAM) {
> 			sock_reset_flag(sk, SOCK_DONE);
>@@ -966,6 +966,8 @@ static int vsock_shutdown(struct socket *sock, int mode)
> 		}
> 	}
>
>+out:
>+	release_sock(sk);
> 	return err;
> }
>
>diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
>index 630b851f8150..5a3beef73461 100644
>--- a/net/vmw_vsock/hyperv_transport.c
>+++ b/net/vmw_vsock/hyperv_transport.c
>@@ -479,9 +479,7 @@ static int hvs_shutdown(struct vsock_sock *vsk, int mode)
> 	if (!(mode & SEND_SHUTDOWN))
> 		return 0;
>
>-	lock_sock(sk);
> 	hvs_shutdown_lock_held(vsk->trans, mode);
>-	release_sock(sk);

Ooops, removing these lines, 'sk' is not used anymore in hvs_shutdown(), 
I'll send v2 ASAP:

../net/vmw_vsock/hyperv_transport.c: In function ‘hvs_shutdown’:
../net/vmw_vsock/hyperv_transport.c:477:15: warning: unused variable ‘sk’ [-Wunused-variable]
   477 |  struct sock *sk = sk_vsock(vsk);
       |               ^~

Since I'm here, I had a doubt whether to separate this modification or 
leave it in this patch.

What do you suggest?

I did it this way because by modifying only the caller, we would have a 
nested lock.

This way instead we are sure that if we backport this patch, we don't 
forget to touch hvs_shutdown() as well.

Thanks,
Stefano

Re: [PATCH net] vsock: fix locking in vsock_shutdown()

[Jakub Kicinski]

On Mon, 8 Feb 2021 16:04:31 +0100 Stefano Garzarella wrote:
> What do you suggest?
> 
> I did it this way because by modifying only the caller, we would have a 
> nested lock.
> 
> This way instead we are sure that if we backport this patch, we don't 
> forget to touch hvs_shutdown() as well.

I'm not a socket expert but the approach seems reasonable to me.

Re: [PATCH net] vsock: fix locking in vsock_shutdown()

[Stefano Garzarella]

On Mon, Feb 08, 2021 at 11:12:00AM -0800, Jakub Kicinski wrote:
>On Mon, 8 Feb 2021 16:04:31 +0100 Stefano Garzarella wrote:
>> What do you suggest?
>>
>> I did it this way because by modifying only the caller, we would have a
>> nested lock.
>>
>> This way instead we are sure that if we backport this patch, we don't
>> forget to touch hvs_shutdown() as well.
>
>I'm not a socket expert but the approach seems reasonable to me.
>

Thanks, I'll send v2 fixing the warning.

Stefano