From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EDEE8306B1B for ; Mon, 1 Jun 2026 09:26:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780305966; cv=none; b=AAsbEt4NmG4nmUz1MZCsONzdMX/cEuAU3VF29gIM0rJ71GLqbrfduVlbruQYwgWXx9UTJpVrL28/S7WSOmlInACy7Q7j8SGRhcpGk9VrwHD3WVyx6dDVBd5U4lv0AfgIrriydVVNqtuQ+5jI8MG3Bdn7pf5WW03nFMQFgPawxFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780305966; c=relaxed/simple; bh=92tjw0qOeTMiu/O2oXMKbRtKwgW0ttd71f9F8miPIDI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LL84L5ZE8sE04QrsB5CPL7kZabrAYwilQukxgFYsYnJrNAQdN+KUaUO/LKEoSm5/dnGX5Zs2fYPmIv4v50efwKyZekGTlR9o6tBu7wPhK4+vulydJ1IyX5fut9Ca7VfEhMKLGlbOaEKORwriGJ1IoV1I7jNmRacsnyq8+dWJ/yc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HikTJyRO; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=fJ3LbKQ5; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HikTJyRO"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="fJ3LbKQ5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780305964; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IbDQ1hQ8dNMnVHUs2DSdKneMuLGxvpohPlMlW5RIgfM=; b=HikTJyROfwiQYpaYqEDFYZxdvCzsY08WtXRqPXvYMhz6X6ykyTteuqOpspCpCd6Yt1pJJI V1jef8kxjQW4Xn6WhzcD8QH8L6nKhWa03gL+THy1W+oGhIN5xOWKWIMQXTQbJ2npQUMCms 8XzqikMWEX3/h1G4uXASiFlX1ieCE0k= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-137-LG6FllwcP4qb65-Q8mnQrg-1; Mon, 01 Jun 2026 05:26:02 -0400 X-MC-Unique: LG6FllwcP4qb65-Q8mnQrg-1 X-Mimecast-MFC-AGG-ID: LG6FllwcP4qb65-Q8mnQrg_1780305962 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-45eef10d5ebso1686663f8f.0 for ; Mon, 01 Jun 2026 02:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1780305962; x=1780910762; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=IbDQ1hQ8dNMnVHUs2DSdKneMuLGxvpohPlMlW5RIgfM=; b=fJ3LbKQ50IBZq/78pg5lpErUoRUkuMPD0sAI8qdqtR83I/N/po/AvgAKDOCYweoBYE ZbRS2xjLr5iEHYwDsNmP2cn6TXlnA8/Zee6RFX0tGfRW9vqoZkuO63ZJNqYzv+ZYgJ9P e2cMFZGqKDRNlRDKcr48v9HGg5Vu0uHXQkcRSysAE/ggGdf6o8YjUqkWSvKRngBNU1mZ U+lDJWOdO42iKQmDMkYoEJ2cxgQ/+DyKBTW2hiba2S+ih9Nezn/iOpisDxW+55e+V4jP XEOyqHj/qSG4gCAjk2VbPciX5HvS69bCFJgjHECR2p5QDhptYIJQM9qVO+dKUeEbp9eZ 5uhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780305962; x=1780910762; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IbDQ1hQ8dNMnVHUs2DSdKneMuLGxvpohPlMlW5RIgfM=; b=Jl6SGQZgXbwfSNc3+PQrwasyqjIcI4STfVrDoyi++7bYCTpSQsKajJqUAAw5f7iZSe 3ZtdUOMsX5afks/lm3OemOs/SNlzjx8AMPTSMFKTOO3q2g+DYpsE5yjTF0jYYlh4DQlJ 5O6TTjOi7BtH/KTb0os+ujpfaI7MG6F1KitYHVDV7K+qyIZZc1kFwS6M7xa+GjJIZi2+ zJyDJ2jCPzTkTkWNjFJ6sdhBKhIbHBX0QY4zdSeAI8Zs50bxCVzpzrtvsMTXAWGtRBTg 5FBBTb2D/0R9wNzK+6j2O2fEN2LTcxcvwJwouGbaqs7KyFpltI0np3cjuus38wrpIQEo MKDA== X-Forwarded-Encrypted: i=1; AFNElJ/SWY4kvzvx+porC9tbIeLL/3KGPV712vBQqUK9hjDR5taRR/pgwdPFGfzJEumdoQ33udhCES6AhCzR22Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yz6NPN/DPrEzxaZAuR1zL5Kq/hji2v2ZLTl1mfDktDYoFVHqNn9 +Vd77hjHPdom1CE85C+8aA9xhEt5VVWD1HoEl59tTGH4OF0c/zwdkDgiyrKJciDNztmPCgCRLX3 8r4PzVKv6ZKcMMjoSUGTULgsG6vK7qU02hH8BXKW9eyTVMEnL1g9214QiIbGzd4hOTg== X-Gm-Gg: Acq92OEbVbKG40UTAaBR06UcjOMuHEYQ3yALyvHFQcZ19zRwVLCTF3bAbf5BrH0+F4L lw8hPRA2i1Wwb7JqhLRQZJrKg7En104NVtXBxCOGn04+dmcCbordIx0N/2l2OMhRVZ50p2jhGGD 5aCOv95Rsrs3VvXCDjBe9dkIKjTsLPglun8ylA0jpwmE1SwT//lrrJg8Lm00LRJgqlWKcfFxOVB 3oHQuHs+h00z4NYzK3jO6iJBdmFk2AAM/yNTZ+kXFcpytufC1rZ/07dkESDBRURwHAefrJVA7ec bJeOTuXewIjqDVB9TzPicINVLMjOFLZw/CGs9W8ndAWV5uHa5Xt9/o6MV3DNNbKt2uteX68ReNR xNhU1MlnVvkFFKEQs3/zznXZEYhubXVclqJW/6yyKiklrKC+Rm77MyscMh02XzxWUcpwJ X-Received: by 2002:adf:ef12:0:b0:43c:ef4f:79e4 with SMTP id ffacd0b85a97d-45ef6ba1e31mr13765428f8f.37.1780305961545; Mon, 01 Jun 2026 02:26:01 -0700 (PDT) X-Received: by 2002:adf:ef12:0:b0:43c:ef4f:79e4 with SMTP id ffacd0b85a97d-45ef6ba1e31mr13765397f8f.37.1780305961103; Mon, 01 Jun 2026 02:26:01 -0700 (PDT) Received: from [192.168.88.32] ([169.155.232.197]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45ef35598e5sm21777598f8f.27.2026.06.01.02.26.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2026 02:26:00 -0700 (PDT) Message-ID: <97069506-352b-4152-a57b-5a974320529d@redhat.com> Date: Mon, 1 Jun 2026 11:25:59 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] vsock/vmci: fix sk_ack_backlog leak on failed handshake To: Raf Dickson , netdev@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org Cc: sgarzare@redhat.com, stefanha@redhat.com, bryan-bt.tan@broadcom.com, vishnu.dasa@broadcom.com, bcm-kernel-feedback-list@broadcom.com, stable@vger.kernel.org References: <20260526104356.469928-1-rafdog35@gmail.com> From: Paolo Abeni Content-Language: en-US In-Reply-To: <20260526104356.469928-1-rafdog35@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/26/26 12:43 PM, Raf Dickson wrote: > When vmci_transport_recv_connecting_server() returns an error, > vmci_transport_recv_listen() calls vsock_remove_pending() but never > calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented > permanently. > > Repeated handshake failures (malformed packets, queue pair alloc > failure, event subscribe failure) cause sk_ack_backlog to climb > toward sk_max_ack_backlog. Once it reaches the limit the listener > permanently refuses all new connections with -ECONNREFUSED, a > silent denial of service requiring a process restart to recover. > > The two existing sk_acceptq_removed() calls in af_vsock.c do not > cover this path: line 764 checks vsock_is_pending() which returns > false after vsock_remove_pending(), and line 1889 is only reached > on successful accept(). > > Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on > the error path. > > Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") > Cc: stable@vger.kernel.org > Signed-off-by: Raf Dickson Waiting for Stefano's feedback - should be back in a couple of days. > --- > net/vmw_vsock/vmci_transport.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c > index d2579380f5..88ccc55455 100644 > --- a/net/vmw_vsock/vmci_transport.c > +++ b/net/vmw_vsock/vmci_transport.c > @@ -980,8 +980,10 @@ static int vmci_transport_recv_listen(struct sock *sk, > err = -EINVAL; > } > > - if (err < 0) > + if (err < 0) { > vsock_remove_pending(sk, pending); > + sk_acceptq_removed(sk); I'm wondering if sk_acceptq_removed() should be bounded in vsock_remove_pending() ? (even if that change would probably be net-next material). /P > + } > > release_sock(pending); > vmci_transport_release_pending(pending);