From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [185.226.149.37]) (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 4E39321C190; Tue, 4 Feb 2025 23:58:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.37 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738713530; cv=none; b=PTb4F9xPsrZAwxvY+eTCuXcr5QuWwmPaVflTRX2tGE9cfJlEsSzpvdrNzI+hYotQXFbVKlds/QCI6O8hGm8bCuQltdjlnpIW2SsfcFYNGB0K8wBupwUGInKl9dt4Sdj66/Ip8GyXs8St7p/Rfrn8q0XIkiwJ5pGM8oREKzZjr0Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738713530; c=relaxed/simple; bh=h1pBuPBtktSjNMu4TvOQ+L+yQZBLCy44jrXjx/GWXb4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s/rEqlHE4RW9flE8YxlX1qzRJFb+E/AK2rZiiby20xMicv2Bix2QeVdLezroOtjiYDlH6gkILctrFhMQkGEx87eRe287vk9vS10BNSOn14R3zXClYTcut4tprP0NNTXO3phbOFL2wy5wrQbJJvKHAaqW0lgI+kVJ5Z6zjfvMrLU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co; spf=pass smtp.mailfrom=rbox.co; dkim=pass (2048-bit key) header.d=rbox.co header.i=@rbox.co header.b=Xlu+gMlT; arc=none smtp.client-ip=185.226.149.37 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rbox.co Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rbox.co header.i=@rbox.co header.b="Xlu+gMlT" Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1tfSoL-005sX9-5A; Wed, 05 Feb 2025 00:58:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=Rb93MMJ9jrAXvrmiXFCfJpGm+j99GvvxBquzJPRoovE=; b=Xlu+gMlT3AX5XzY+BkrKS8QIfr 946QTIjd72Jt3evMzv5wMJHT1IBhZLJSWMFthKc1Vvs5jh1/YL3155+u+sMeyECO9VPsZO6NEmMdn OtVfJQsu5oZxKA1bcv4WRF6h4M6h8v3dNVVWTgYbUilvMvss2FTiACakY/uO/wpH1Gg46k6zbuTt+ 3Gdt42+2/lOC1AiKjohd1FWKwEtHVxsYNC0hWCYy0A03nuxyFIr4l0TZHaqzWkW26xk0hkNeFh7lt QP8JCsLD20C4fzTk5jtjH7dzAu7Y8R94WqNWOJzAGjEsF5x0ePgIIQ79L1pMkHqAbDFzrNXt2p4iZ ByRYmBOA==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1tfSoJ-0002IE-WD; Wed, 05 Feb 2025 00:58:32 +0100 Received: by submission03.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1tfSo2-009Y7j-C5; Wed, 05 Feb 2025 00:58:14 +0100 Message-ID: <4732bd9f-e202-4895-9ba2-576b571c387a@rbox.co> Date: Wed, 5 Feb 2025 00:58:12 +0100 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: [syzbot] [net?] general protection fault in add_wait_queue To: Stefano Garzarella Cc: syzbot , davem@davemloft.net, edumazet@google.com, eperezma@redhat.com, horms@kernel.org, jasowang@redhat.com, kuba@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, mst@redhat.com, netdev@vger.kernel.org, pabeni@redhat.com, stefanha@redhat.com, syzkaller-bugs@googlegroups.com, virtualization@lists.linux.dev, xuanzhuo@linux.alibaba.com References: <67a09300.050a0220.d7c5a.008b.GAE@google.com> <2483d8c1-961e-4a7f-9ce7-ffd21a380c70@rbox.co> <6fonjxxkozzmv7huzavck5nsfivx3nsyyicthulg5aiyrmjpql@o7pexllumdxt> Content-Language: pl-PL, en-GB From: Michal Luczaj In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/4/25 11:04, Stefano Garzarella wrote: > On Tue, 4 Feb 2025 at 10:59, Stefano Garzarella wrote: >> On Tue, Feb 04, 2025 at 01:38:50AM +0100, Michal Luczaj wrote: >>> ... >>> I'm not sure this is the most elegant code (sock_orphan(sk) sets SOCK_DEAD >>> on a socket that is already SOCK_DEAD), but here it goes: >>> https://lore.kernel.org/netdev/20250204-vsock-linger-nullderef-v1-0-6eb1760fa93e@rbox.co/ >> >> What about the fix proposed here: >> https://lore.kernel.org/lkml/20250203124959.114591-1-aha310510@gmail.com/ > > mmm, nope, that one will completely bypass the lingering, right? Right. Besides that, it's a transport-specific approach, so all the other transports would need their .release() tweaked. >>> One more note: man socket(7) says lingering also happens on shutdown(). >>> Should vsock follow that? >> >> Good point, I think so. >> IMHO we should handle both of them in af_vsock.c if it's possible, but >> maybe we need a bit of refactoring. >> >> Anyway, net-next material, right? Yeah, I guess. Michal