From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 024E941D139 for ; Wed, 5 Aug 2026 10:29:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785925788; cv=none; b=CuiHLDYAUxFDxCBN2U7oady5wmKm8ovlyO/nOxxCijbFCvTr9F7ljWiMu0xzjZhCK0AHodbQ4LH9JcuLTnTsZ5raJa3zCBQayebdGWjTPNoSgVylQuFjr3e1poCI3dpVsAyXma3BXKe+CQjm6/7FPbTy7LwoFeLIbRhlXr4yY2Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785925788; c=relaxed/simple; bh=uZIfQ2ep+zKP+NQDe+F559/YOsSB/WrZVinoZfDAncw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KCWXuphusSTTsBQbik004z6/XOl2hTVj3Sp6yonGsbSPZzuMzU/TPCyBnZhpBCE7AUtdsaLuWXsl8HPfrZnuRyPqu75uhTsi7BG/lHlAuToim+6pBRWIJoE+oCFb/13RJ8CurJonWEyo6L5K6q+Uan6ojLuMkq2sd/BoEuTFheM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jp3zuuOT; arc=none smtp.client-ip=209.85.216.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jp3zuuOT" Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-381b831d535so951414a91.0 for ; Wed, 05 Aug 2026 03:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785925782; x=1786530582; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=3CobWGezPJ1jiz14fyzEAXpAWQpNHtzLmWbtrjHOhKU=; b=jp3zuuOToTs1Ja0zQ60LpeVbx3LKIylwusVdHmiRAdLDahU+N+hZClLSlLtbvrTMT3 fUVKUfjRU12P1rlRAjGCt2Eouubm34gYaoEYvq2BMcfldaVM0P1GlKoyU0ue9L7fcnLS 9g/kNjqRN586Z4xR07ttO66L6aNANPLZbCtspyZroKf7V0lHKQW0IChG3UW1N/zc3USz sc6mFmQsc6K0YUFMuFGV+LEPvZk4AsK8l5yklh5RK17rpYUiCDC+oyk5MX29XbMsK79Z Qz0/ABE0mSJ3luPLTg/hGtmQmlrdMStRvPbeJ5qoQP3OsuHFRwW03uXYYuUiak0O7UZe XNFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785925782; x=1786530582; h=content-transfer-encoding:content-type:in-reply-to:from :content-language: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:content-type; bh=3CobWGezPJ1jiz14fyzEAXpAWQpNHtzLmWbtrjHOhKU=; b=CFN/Ee0nhhQxGrJsMqPX1/9hEly5xyvl9Vn7aQR8X5gl8K0YnsjXFVKnl4ByAEu5eh tmsCY2zilqU/X5YA7A4H9hAkVXl/u4DqBU1gVGWNuMhv/yfisbyd2QtJnvs9aEJYcWDi GMnc/8oKowmkMWesATyMUCd+cLPdJnjfhUrGgZINqKeUQN327D+8JHfRMnA98/zpY36m ltmyRxDALubED7ypjQ9wqGvUiPMZpaG/B4ziq+GSApOMT/pdwgSyBejaWFb0PR0xFZAX 5eEeJT0FFTdq31OsEnoQ8nBRHMoLIG8DBSMHlH2gbEtY7D6R0PeM/9ImJnYM3gwW7a1A 351w== X-Forwarded-Encrypted: i=1; AHgh+RoyUQ27o0s7dAYWXhBG6PMCSTAdAYFiNLpGoHCe8fTZpYa7ar9JcMh6p7vjdtEv5rlfA6RJMmw=@vger.kernel.org X-Gm-Message-State: AOJu0YxR4hFSPhlzYjBB7ryDvcx2fn9RpWQRUsec3FjXJYyl4Li8aXkm ZXn1m1AonMRFWsm81ggKFUokLIEPWy3muzSjUPqL88x3OvsIQLO7sDba X-Gm-Gg: AR+sD13XO8KJ0nhENJc6QEZzQQJf/8iN2FTdgW8bb+pNYaymh+6AgX5WQn2dgvRJ4yS ZGDpZ52GpbfNhrUcRtFKHHRPlwtEM1MsVG8rkPqYlwmdWVldaMAdd6ua3BUWenRw6NXjg1rzUbQ KH7rj8Cb5CvB2RkGHBNf4OYiuVFU9w5bFJolpXXyn2C47Lw2itEURKl3II1lj4vfF5lEuQ4wdy3 iK6Jx4BmxNImA2wt7vy71SrKuyBBkCCRAMTKmHq9FB3ycePTHpwrPfDf2zcq/8dygqdmZccwaE0 wr0shOeR1WEUR9GsDkRrJb7YxB597PrQjm30pX1NJsCkKLGkVAbDcSHRAfOWdrOX057uJuH7zRe lyfDCLyqk6YT8cnxfCA+aIkB3/ir8/waObxhdWIf0VDrtSfcOMepKy0WPsv0Ka6vyxrEUBXpfDJ Q9Q0wIjt4U/+FFUwGcOIvzw2AD/a/xSYd/xuQ1U4QDRAoRFfNjJuwbWbI/eNZD3E1FmKfToVKLA IdVgzfGWzRsADsVlg== X-Received: by 2002:a17:90b:57cf:b0:38e:4f41:83df with SMTP id 98e67ed59e1d1-3903c5b34edmr6522051a91.15.1785925782493; Wed, 05 Aug 2026 03:29:42 -0700 (PDT) Received: from [10.22.76.20] ([118.201.124.118]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-390392aee23sm2798253a91.15.2026.08.05.03.29.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2026 03:29:42 -0700 (PDT) Message-ID: Date: Wed, 5 Aug 2026 18:29:36 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] vsock: use sock_error() to consume sk_err after a failed connect To: Stefano Garzarella Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andy King , George Zhang , Dmitry Torokhov , syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com, Michal Luczaj , Wupeng Ma , virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260804135238.386417-1-phind.uet@gmail.com> Content-Language: en-GB From: "Nguyen Dinh Phi [SG]" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/8/26 16:34, Stefano Garzarella wrote: > On Tue, Aug 04, 2026 at 09:52:36PM +0800, phind.uet@gmail.com wrote: >> From: Nguyen Dinh Phi >> >> Syzbot reported an issue which can be reproduced with these steps: >> >>   r0 = socket(AF_VSOCK, SOCK_STREAM, 0) >>   bind(r0, {VMADDR_CID_ANY, PORT}) >>   connect(r0, {VMADDR_CID_LOCAL, PORT})   -> -1, EPROTO  (self-connect) >>   listen(r0, backlog)                     -> 0 >>   r1 = socket(AF_VSOCK, SOCK_STREAM, 0) >>   connect(r1, {VMADDR_CID_LOCAL, PORT})   -> 0 >>   accept(r0)                              -> -1, EPROTO  (stale sk_err) >> >> Basically, it creates a socket (r0) and triggers a self-connect after >> binding it. This self-connect fails with EPROTO because it loops back to >> r0 while the socket is still in the TCP_SYN_SENT state, causing it to be >> incorrectly dispatched to the connecting-client path. The unexpected >> packet type encountered there sets sk_err to EPROTO. >> >> After that, it invokes a listen() call on the same socket. This listen() >> call succeeds because the kernel's listening path never inspects or >> clears sk_err. Then, a new socket (r1) is created as a normal client and >> connects to r0. However, vsock_accept() rejects this incoming connection >> because the listener's sk_err still holds the EPROTO error from the >> earlier failed self-connect. >> >> This rejection causes the child socket created for r1's connection to >> never be freed on virtio or hyperv transports; only the VMCI transport >> implements pending_work to revisit and clean up a rejected socket. >> >> Fix the issue in blocking connect() by using sock_error() to read the >> sk_err to prevent the rejection branch from occurring in this scenario. >> >> sock_error() atomically reads and clears sk_err, ensuring the error is >> consumed when vsock_connect() returns and cannot affect subsequent >> operations on the same socket. This matches the established pattern >> used by other protocol connect() implementations in the network >> stack like __inet_stream_connect(), tipc_wait_for_connect()... >> >> For non-blocking connection, vsock_connect_timeout() may set >> sk->sk_err after vsock_connect() has returned. To handle it, we also >> remove the sk_err checks from vsock_accept(). Nothing in vsock sets >> sk_err on a listening socket, so accept() has no reason to inspect it >> at all. >> >> Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com >> Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678 >> Fixes: d021c344051af ("VSOCK: Introduce VM Sockets") >> Suggested-by: Michal Luczaj >> Signed-off-by: Nguyen Dinh Phi >> Tested-by: Wupeng Ma >> --- >> V2: Add reproducer steps to commit message. >> V3: Fix truncated title and add annotations to reproducer steps. >> V4: Remove sk_err checks from vsock_accept() >> >> net/vmw_vsock/af_vsock.c | 13 ++++--------- >> 1 file changed, 4 insertions(+), 9 deletions(-) >> >> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c >> index 622dbd046799..594fe27d2ebe 100644 >> --- a/net/vmw_vsock/af_vsock.c >> +++ b/net/vmw_vsock/af_vsock.c >> @@ -1847,12 +1847,10 @@ static int vsock_connect(struct socket *sock, >> struct sockaddr_unsized *addr, >>         prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE); >>     } >> >> -    if (sk->sk_err) { >> -        err = -sk->sk_err; >> +    err = sock_error(sk); >> +    if (err) { >>         sk->sk_state = TCP_CLOSE; >>         sock->state = SS_UNCONNECTED; >> -    } else { >> -        err = 0; >>     } >> >> out_wait: >> @@ -1893,7 +1891,7 @@ static int vsock_accept(struct socket *sock, >> struct socket *newsock, >>     timeout = sock_rcvtimeo(listener, arg->flags & O_NONBLOCK); >> >>     while ((connected = vsock_dequeue_accept(listener)) == NULL && >> -           listener->sk_err == 0 && timeout != 0) { >> +           timeout != 0) { >>         prepare_to_wait(sk_sleep(listener), &wait, TASK_INTERRUPTIBLE); >>         release_sock(listener); >>         timeout = schedule_timeout(timeout); >> @@ -1906,11 +1904,8 @@ static int vsock_accept(struct socket *sock, >> struct socket *newsock, >>         } >>     } >> >> -    if (listener->sk_err) { >> -        err = -listener->sk_err; >> -    } else if (!connected) { >> +    if (!connected) >>         err = -EAGAIN; >> -    } >> >>     if (connected) { > > Can this become an `} else {` ? > > Or just add a `goto out` when setting `err = -EAGAIN`. > I will update it. >>         sk_acceptq_removed(listener); > >         lock_sock_nested(connected, SINGLE_DEPTH_NESTING); >         vconnected = vsock_sk(connected); > >         /* If the listener socket has received an error, then we should >          * reject this socket and return.  Note that we simply mark the >          * socket rejected, drop our reference, and let the cleanup >          * function handle the cleanup; the fact that we found it in >          * the listener's accept queue guarantees that the cleanup >          * function hasn't run yet. >          */ >         if (err) { >             vconnected->rejected = true; >         } else { > > > Should we update this comment too and maybe remove the `if (err)` at > all. With that change I guess `rejected` is never set at the end and > maybe we can remove it at all from `struct vsock_sock`. > > Looking at commit d021c344051a ("VSOCK: Introduce VM Sockets") where > `rejected` was introduced, I can't see any path where sk_err is set on > a listener socket, so I guess that path was dead since the beginning. > That seems true, let me verify it. > So now I'm thinking if it's better to split in 2 patches (both with the > same Fixes tag): > - Patch 1: "vsock: remove stale sk_err checks from vsock_accept()" >   Where we can also remove `rejected` since it's never set to true since >   the beginning > - Patch 2: "vsock: use sock_error() to consume sk_err after a failed >   connect" > > WDYT? > Yes, I felt the same when I was writing the commit message, but honestly I didn't know that I could split it into a series when sending the new version. So, it may contain 3 patches, if the rejected flag can be removed from vsock_sock. Thanks, Phi