From patchwork Mon Oct 5 15:26:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 268183 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03D40C4363A for ; Mon, 5 Oct 2020 15:29:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C51EA20874 for ; Mon, 5 Oct 2020 15:29:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601911750; bh=cDRAHB+D7GHBCtXoKIFf++muchShCNXU5Qepjm5VBy4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=vdS2zG+nVt4PKHizraCP9VfVYXTQW9WJ9PWIuF2HB6HF/BioUqfbcpQZX8vrvlbz9 i1xgp5z6GEGLaROxmbNcfwU+2rQc1WE/OnNlNcWrXC2goIPHBWbbsyhF6xn75PEUqV PudKIAVsRIATwYfbkc1il/IRnJXHtQLF80nyjsmo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727475AbgJEP3D (ORCPT ); Mon, 5 Oct 2020 11:29:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:53922 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727476AbgJEP2w (ORCPT ); Mon, 5 Oct 2020 11:28:52 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 42A71207BC; Mon, 5 Oct 2020 15:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601911731; bh=cDRAHB+D7GHBCtXoKIFf++muchShCNXU5Qepjm5VBy4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m9wM7P4QpXhkRYMkankJNtU5f21mXM19jS8asnSAn6YGeRogpU2q9ykMqHbdYxjbZ prMpOnxi9dLczr40NJ81sgHxKxaX7iH6rmv/abmsx+7wg3FfL3s59IKeaaRNbjWNXZ M2Vc28uc+4byU77VOXb/EjCibaPBOt2+rN7iqZCk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sebastien Boeuf , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 09/57] net: virtio_vsock: Enhance connection semantics Date: Mon, 5 Oct 2020 17:26:21 +0200 Message-Id: <20201005142110.252526087@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201005142109.796046410@linuxfoundation.org> References: <20201005142109.796046410@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sebastien Boeuf [ Upstream commit df12eb6d6cd920ab2f0e0a43cd6e1c23a05cea91 ] Whenever the vsock backend on the host sends a packet through the RX queue, it expects an answer on the TX queue. Unfortunately, there is one case where the host side will hang waiting for the answer and might effectively never recover if no timeout mechanism was implemented. This issue happens when the guest side starts binding to the socket, which insert a new bound socket into the list of already bound sockets. At this time, we expect the guest to also start listening, which will trigger the sk_state to move from TCP_CLOSE to TCP_LISTEN. The problem occurs if the host side queued a RX packet and triggered an interrupt right between the end of the binding process and the beginning of the listening process. In this specific case, the function processing the packet virtio_transport_recv_pkt() will find a bound socket, which means it will hit the switch statement checking for the sk_state, but the state won't be changed into TCP_LISTEN yet, which leads the code to pick the default statement. This default statement will only free the buffer, while it should also respond to the host side, by sending a packet on its TX queue. In order to simply fix this unfortunate chain of events, it is important that in case the default statement is entered, and because at this stage we know the host side is waiting for an answer, we must send back a packet containing the operation VIRTIO_VSOCK_OP_RST. One could say that a proper timeout mechanism on the host side will be enough to avoid the backend to hang. But the point of this patch is to ensure the normal use case will be provided with proper responsiveness when it comes to establishing the connection. Signed-off-by: Sebastien Boeuf Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/vmw_vsock/virtio_transport_common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index f0b8ad2656f5e..efbb521bff135 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1127,6 +1127,7 @@ void virtio_transport_recv_pkt(struct virtio_transport *t, virtio_transport_free_pkt(pkt); break; default: + (void)virtio_transport_reset_no_sock(t, pkt); virtio_transport_free_pkt(pkt); break; }