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 2577742FCDA for ; Tue, 4 Aug 2026 09:37:50 +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=1785836274; cv=none; b=oxwDlkbZBqSMyeiTuovR3vcVNAOifPN2AbLVNXfZJAHupCY8RFEevCKLUbDYWPPcZ1fvyLuwvMe1GaCQNB6AVRRvD5T2sRqv8OSEafm66QprC1qIfAgCgNteaVVag9uZei13WTo0/k3p5vvIMz07FMe5TgyEfhwzH07B6zZM1qU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785836274; c=relaxed/simple; bh=YHCzNxOR8vzG0iWXONmBMTdnogbrhp36qxhg1+Egca0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JBwXh7+8S0W34UVk/9wZSnfgu2olJnjQ6t0V44PF8X8EOZ/CpBiIlG+I/BuwE9Zv+RcLx2/coyzFIXacAwhN/W+d1fy8rTBna0tOh+tiQARoxmqq808cpQS1xfQ+RtXwe16W1w16nDr8ZE8jH4UZRjCGyBtfQUIdVEZo0FOKvnE= 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=dnC7WCdL; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=DHAij9fo; 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="dnC7WCdL"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="DHAij9fo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785836269; 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=EM7xpqXAUJNazCozbweIvpU+TjAspQcIOmydlbjLiPo=; b=dnC7WCdL6EEIS6Bnp5Ns6N94jQVqLoOnQoio+6kqe1YYE/ZQ/fLqYM7tYjLhb60uyk0VwB qi9zoJ7VrkPdsPMdSrrnLhcRhD0d6mkNOsoQ58oMPUaEq18jFYIBbWCND0vLBn6ac22ijQ 5epmCe0vp64jLGL8Q5DBkqgLybTd+Qs= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-628-vKERev2XMUm1VU4lYjk2Sw-1; Tue, 04 Aug 2026 05:37:48 -0400 X-MC-Unique: vKERev2XMUm1VU4lYjk2Sw-1 X-Mimecast-MFC-AGG-ID: vKERev2XMUm1VU4lYjk2Sw_1785836267 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-49808ea1b64so10470735e9.1 for ; Tue, 04 Aug 2026 02:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785836267; x=1786441067; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=EM7xpqXAUJNazCozbweIvpU+TjAspQcIOmydlbjLiPo=; b=DHAij9foOmWtR7wbCNRrWWFGwdRE3O6SFA9FoguTPzoZ0obRnrmhYhdrQit3Sev549 CytQD/xL2PhwGG5U5/QZ1N1LV92F6i316QPAqbEa5oTNX/LHJQArImryJiJLITykGA88 oAGcFjOcmbgG51m3WwkdJbppcrkNJpwDCHEmUH60P0r/0SMbmS/suzEMs12qiTwy1bp6 BOsDAP2hGEelvPqe9P//Z29Ef+YwdzkktSTRZrWh2ybnrHOD7L8ZHKqoWij2q0A1oico VoBfNvWj/goYuSpbbWXkQdZjFIIrDGQ1fMeY7fYw5Cz8fiPLAKRoG/MXMuJdXV5S+PUy myTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785836267; x=1786441067; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=EM7xpqXAUJNazCozbweIvpU+TjAspQcIOmydlbjLiPo=; b=CcxNloHrdDhUQsEMpC7562VjalqoJHYe3hibTaVpm+0fEkJxGdy9+4P0q4h4yZW5zh /iqXiGW18+HnZkPuNG0Wif6Ikh04JXziLQ9wIzAqA/xsJ7zid60Jng+Qdyu8/Ea/RWkx Uxk+Xfr7hepd4YSFDzmZJ0cm6ZlB/ojQJbLZjFWbrwUtoGNEFk9yzunOSg0GM0Pjd0Ec cIrEt014/ATvoPGWDQW1qdWkLSwpJb/h1EKTIvg6MkDH4DCutHXCswVOBl0HW6Wzumh8 jxTYDzHn/iayaCAV35GfnFq907szbgjbXkULD0vmP1sC3zx82pMQxOeCIRbIvJ+yjKhk tGdQ== X-Forwarded-Encrypted: i=1; AHgh+RoSBq3jj1DtrA91HTnOimipyfCl55a/5eGPFHbSEuXbbaaBc6GOsR7NCe10Wg7UaTEc/by7kG3d6MTcqUw=@vger.kernel.org X-Gm-Message-State: AOJu0Ywzjy4jkff+l7nwVih+tk0oJSDPO263AyPccNqqBLlt8z+gXWtT 8uGPG/VxU+V7ZVd9MYkVT49+c7B/xe2fD/aYZZLRh6Q92CZiEat09cDSZ8A0Hpm6GJV7gpXrVNl vw3lpSFybKeDeJdcEzb5qb+/QiLE0DQrQWQiuI/r/W9BKtx0MtwLEmZwBpJckRs676Q== X-Gm-Gg: AR+sD12bTgFiNXXPhlaGEcOJS81KW/nEJ8XBScjSq2bEEiCz7T5GH34VxB0c52lVBVZ RnLO6c+P4yPL6x5QoZHyTnSr3k+sQLcE5vxH9XfUe4bCv6Ux0GSQvPg0612Jq/RfUvWpFpNZKS0 2QjmTMJ7XbCo1FZ01/KWrVB/n4OjS+s1nbs7yIXGFTRbrP3KijzsglQN7T/+2aVMER6r21bN5hG /ab8jIFlpFBGxniTC7t9CYxKe9LMaogIO/yaVyDmYO/sDeI4z5aNEXZciC+rPm375OUUO5To2S/ V55uAaQwdnFCyy7ZVxIFh4VZ3g1lj92GEC3lUrvgCaM3FImh49uAPiKRDHXeCpB9F2XTtmRCR9E EYfU= X-Received: by 2002:a7b:ce08:0:b0:495:5d6d:9cc1 with SMTP id 5b1f17b1804b1-49949f89850mr56638915e9.0.1785836267190; Tue, 04 Aug 2026 02:37:47 -0700 (PDT) X-Received: by 2002:a7b:ce08:0:b0:495:5d6d:9cc1 with SMTP id 5b1f17b1804b1-49949f89850mr56638165e9.0.1785836266578; Tue, 04 Aug 2026 02:37:46 -0700 (PDT) Received: from sgarzare-redhat ([5.11.104.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49949fec606sm86248365e9.14.2026.08.04.02.37.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 02:37:45 -0700 (PDT) Date: Tue, 4 Aug 2026 11:37:37 +0200 From: Stefano Garzarella To: Paolo Abeni , Michal Luczaj Cc: phind.uet@gmail.com, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Andy King , George Zhang , Dmitry Torokhov , syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com, Wupeng Ma , virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] vsock: use sock_error() to consume sk_err after a failed connect Message-ID: References: <20260730081843.287563-1-phind.uet@gmail.com> <6a2958d9-5d16-404a-ac02-21940e90162d@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: <6a2958d9-5d16-404a-ac02-21940e90162d@redhat.com> On Tue, Aug 04, 2026 at 11:26:57AM +0200, Paolo Abeni wrote: > > >On 7/30/26 10:18 AM, phind.uet@gmail.com wrote: >> From: Nguyen Dinh Phi >> >> Syzbot report 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 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()... >> >> Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com >> Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678 >> Fixes: d021c344051af ("VSOCK: Introduce VM Sockets") >> Signed-off-by: Nguyen Dinh Phi >> Tested-by: Wupeng Ma >Sashiko nipa points out that the race still exits: > >https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260730081843.287563-1-phind.uet%40gmail.com Yeah, it seems the same conclusion we reached with Michal on v1 and Phi agreed on: https://lore.kernel.org/netdev/148e56ec-dc26-4be2-a7af-eb547b517a68@gmail.com/ Not sure why sk_err check was not removed in vsock_accept. Phi can you check? Thanks, Stefano