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.133.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 6FC714657F5 for ; Tue, 19 May 2026 09:42:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779183725; cv=none; b=HCHe/NhCtKbpoJQfvuCytARiiuod/feyFbr/iuR0TT5l0Bf20J2qXsb+KSMC/i/B5BjPB+mpZdkH8YCAQ7pL/ip46rluM4Ehn9w5gsJhEARMmVW2Gj5qsIwvcyAyZu3NYBLj8ah67uJ7SgP+AqkjCC4fbY5xxitThKXEDUAoGv4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779183725; c=relaxed/simple; bh=yt0H3bvBRFcuJ9DYVM0S3Grsofv+ydRaNi8hw/H/mjI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Pw7Ky197pL89Pyc3FJhukKGTFkuHNAX3lkZetD0QQR4fTxeo9S0xsK6IcUmKx9N8fBLdPczrhOR8T7QUwv4Yq1BRD2O5gJPjFhtny3j+EKQP+Hf8uLujyDklTW+iwPeKkpWlZSbX/p2hcYITgUxXSJVE2R6PRL4c2LYGWRzqz9M= 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=aIbrnRCE; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=MO2yYzcL; arc=none smtp.client-ip=170.10.133.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="aIbrnRCE"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="MO2yYzcL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779183717; 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: in-reply-to:in-reply-to:references:references; bh=tk6v1iOlM6Sc6be+bYwuVr8WIaK4VMHqbDmDqfyVw54=; b=aIbrnRCE4OuemYbpTQPAAZzbf1WCGqr92GHgtVlgjdGlb9h8k4+KHNRnkSZqRzKQuppJQr gwifdvjuBC4sHqTPqS0OeBJsCvCVSK7JaQRO4JL4G/VlHyl8WfS5Esp+jvs+IGA6Y4fGB8 deKKQXVO2OQLh4Dl2AEmmxUTEtGoVks= 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-542-g3adzfzgMO6oDxAeieQNeg-1; Tue, 19 May 2026 05:41:54 -0400 X-MC-Unique: g3adzfzgMO6oDxAeieQNeg-1 X-Mimecast-MFC-AGG-ID: g3adzfzgMO6oDxAeieQNeg_1779183713 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-45aeac88af4so2729170f8f.3 for ; Tue, 19 May 2026 02:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779183713; x=1779788513; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tk6v1iOlM6Sc6be+bYwuVr8WIaK4VMHqbDmDqfyVw54=; b=MO2yYzcLm49L+93RMyfoZ7e3aSRE0Vt6y/zTmzYK3ivNwMrBbGczvi692nr+ZeTdoJ HihyHPxRIxa13cvSWsGidW2MvMvaef5gCYGkMcQNC46Si8moHcHAAWYkAFGKATDL24ue 8LMNeHpPBIC9EjrD/anW7wBw+UKaIlBX4gEvX5wKOyIvyDPVvGVbxHIGY2C3vt9D9+jT XF1kSxWcvfHfNo3B87rxrwr+nC/ixJD7O9dozQnvlq9HhbrluTL6y0uAFdC6VQ8252ok LYtHeZBpDgjKyoecZIUNQdJiIvlNVp250dFO+hragUSVR1EGxYF/OSNQBLDe3g34LO1v /ZRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779183713; x=1779788513; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tk6v1iOlM6Sc6be+bYwuVr8WIaK4VMHqbDmDqfyVw54=; b=LkQATd2cEbsYs/WPz7Psuaap69Q3+jyMHibCEuZyzBZTMVG5/4eyssDaUhDOAXth0F rDurzYSa2p/cXkF5K6REo6gfBFzWKasGdm9V83JCCRWs4SNlEV4Edw6mhx1TBIvS1Gno osXyUaGURAD1jkUvvTFrbYcCiLRIqMOHgS8RyqALadq2umqu9/AJ70s5XSUOVvYQmZQX voZJawE1yKaj4pH0cxF94B2ddQTuEq1GwD6neeOt9DXRbafe2lFVl/kJgInzURVJuJRi igyH55RoamKoNycRmeCZA0aHT+v0HJhsa7I2jdmcGrK/whCahLMww1VyWmONSUjFNjF4 gbrA== X-Forwarded-Encrypted: i=1; AFNElJ/xyVZX1oPDvDVDcYCOtwBfQo0OawbR+IrYfvZj6PhwQVf5emHNsFzidjyzUfnCJoKwYhypjeqvt9dkf5Q=@vger.kernel.org X-Gm-Message-State: AOJu0YxJLS2DgyEoSvDvr57JRjQbRYgS2D+TDYjVeiaL3WCb57VmoTXq 6yeZC9wiJx5/p0ph1aO28yWvQIb2vQELzDCik6JdBaYraMeOZ6CSnTdLL1FzUCyoEK2/Hci1nkm GKKyTbSEt0mDEni8jn1Y/916w+ZC9F2nvE7EB7FZjjms25RkP5r+FUTtMX3rn2tQFaA== X-Gm-Gg: Acq92OHdbA0cmOmA13nRtKlUL4zAcaz9hrKwpHMr+XH/XX5SoATjqrJtc7FZvjbS6G+ DgNb7tMG3oRpcMfbmBNODg9tHGIbixCcHVombQFZWSHDIjDSxnF1xACGqCTyFiPUEXE/6CffLtA R8UzUMa71TregCAD9FZKkBTNbTYYhAZ7C3p09n0aSgFmzCAr1o4fMQA+beaVsaVCA6d8MoZhb/6 b/o31Wuh2bL90X0gWUgthBfWN9og46V58t8R/qMbWtvUybh9lMO2zNmQp2g+f+Uy2NRpCv0hyUQ 324lDB7n5XmmeUIq71TzyRNkK5ZVh50NeRqWVY5zgu6x2vxRL7b0V/f10EdXW0Y9LrY4Shy4WCv o+EAk9VlbEhU3wLAdXqt5IlG4677g+I+8TKGfDLY+WPyC5kbXO+MMdT9wfShlSWmt0KIUIt9u8Q == X-Received: by 2002:a05:6000:25c1:b0:43c:fb48:6856 with SMTP id ffacd0b85a97d-45e5c5af3c9mr35164469f8f.13.1779183713259; Tue, 19 May 2026 02:41:53 -0700 (PDT) X-Received: by 2002:a05:6000:25c1:b0:43c:fb48:6856 with SMTP id ffacd0b85a97d-45e5c5af3c9mr35164400f8f.13.1779183712778; Tue, 19 May 2026 02:41:52 -0700 (PDT) Received: from sgarzare-redhat (host-87-16-204-231.retail.telecomitalia.it. [87.16.204.231]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45d9ed2f738sm43263408f8f.16.2026.05.19.02.41.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 02:41:52 -0700 (PDT) Date: Tue, 19 May 2026 11:41:44 +0200 From: Stefano Garzarella To: Paolo Abeni , Minh Nguyen , Bryan Tan Cc: Minh Nguyen , Bryan Tan , Vishnu Dasa , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , bcm-kernel-feedback-list@broadcom.com, netdev@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH net v2] vsock/vmci: fix UAF when peer resets connection during handshake Message-ID: References: <20260512025851.189140-1-minhnguyen.080505@gmail.com> <3518e2b5-b669-4aaa-82ca-bbf479a85889@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3518e2b5-b669-4aaa-82ca-bbf479a85889@redhat.com> On Thu, May 14, 2026 at 03:26:28PM +0200, Paolo Abeni wrote: >On 5/12/26 4:58 AM, Minh Nguyen wrote: >> vmci_transport_recv_connecting_server() jumps to its destroy: label >> and performs an unconditional sock_put(pending) to release the >> explicit sock_hold() taken by vmci_transport_recv_listen() before >> schedule_delayed_work(). The existing comment claimed this was safe >> because the listen handler removes pending from the pending list on >> the way out, which would prevent vsock_pending_work() from dropping >> the same reference later. > [...] >Sashiko says: > >--- >Could this change lead to a socket memory leak if another packet arrives >before vsock_pending_work() executes? >If a peer RST is received (err == 0), the socket stays on the >pending_links list with its state set to TCP_CLOSE, and the base >reference is kept. >If the peer then sends another packet (such as another RST) within the >delay window before vsock_pending_work() runs, >vmci_transport_get_pending() might find this same socket. >Since its state is TCP_CLOSE, vmci_transport_recv_listen() would hit the >default switch case, set err = -EINVAL, and call vsock_remove_pending(). >This removes the socket from the list and drops the list reference, but >it bypasses vmci_transport_recv_connecting_server(), meaning the base >reference is never dropped. >When vsock_pending_work() runs later, vsock_is_pending() evaluates to false. >This sets cleanup = false and bypasses the sock_put(sk) call, leaking >the pending socket. >While not introduced by this patch, does this error path leak >sk_ack_backlog slots on failed handshakes? >If a handshake fails due to an error, vmci_transport_recv_listen() >handles it by calling vsock_remove_pending(). This removes the socket >from the pending_links list but does not call sk_acceptq_removed(sk). >When vsock_pending_work() runs later, vsock_is_pending() evaluates to >false because the socket is no longer in the list. This causes the work >function to skip its own sk_acceptq_removed(listener) call, meaning the >listener's sk_ack_backlog is never decremented. >--- > >it looks like the above is trading an UaF for a leak ?!? > @Minh @Bryan can you check this report? It seems a real issue, so the patch was not applied. Thanks, Stefano