Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp2993916pxt; Mon, 9 Aug 2021 14:07:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwA91ImSLyvuCc9XXaFk8hybZb08aY2ejMMzgx49GTrb0PdyuuzFG1qWl8xLUAaTex7HxBi X-Received: by 2002:aa7:dcd1:: with SMTP id w17mr323593edu.322.1628543227938; Mon, 09 Aug 2021 14:07:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628543227; cv=none; d=google.com; s=arc-20160816; b=WbyPN8Ozj7MxE3zbMSBil/ardZF9i9IzILUz6pwwVxafctD0lhtK0Zt8MzojhEct7R wLSlikD+P5sELWjqUD+hfeRAejpjxV8powWPx26pSmd6kUTB7N3I9rx0M8W4f8oOnYc5 p9QspK9tkmmvkMmWiWSfGGi2kpHpCdzYSOTkmtwBbdry5c/0FgXNBwE9f8ahjvPtwoxP KlATRUPAmZaFbhAvWACquwwbDK18kJZEqoTLDkfgPElAogIzSwpw7UMQlsbHBz4DeYQO uLWyJn9aGx46mvwT3T9T2OUkfWhS2SJ4WKo49cG7h6YsPkNSAIb7pbmOlv4FKx9o48Oi 2M+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=LkYZEJ0/audFjk1Y+4gJ/kDbWnAX8ImpUddYHWA92q8=; b=nnVE1fKWVxfPtVspVBCF0mBvfIYfhM26FsuCBVFO8tqeXiu/EyC979QRW+9N5r9ksr yoAfb2T6vPgfDinIkXpcqcbuwgujttSnzTQS6AoQGZeZxNNFzVkooU/hzFUuETAu3svJ 6woAtKPB/2BlXNpHNg2mPSUUc4q9jvKEniTE9VvX70JT0/YVt2yS4CkdjUpVfigcnGcQ EbrR/fKoPINGRI8pn3JykhstDWoGpr0PuWfdgJAK6uhN7BeXLO4XH2QQq/sGaB1zrFrS VHqmM6gDc+F8wRNHWhRR0TG6UXpovwPdRtnzNB0dRKFouVolOR+wS6NgtVzqQchHyZHj WpUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t14si8169934edr.573.2021.08.09.14.06.38; Mon, 09 Aug 2021 14:07:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235657AbhHIT7o (ORCPT + 99 others); Mon, 9 Aug 2021 15:59:44 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:58706 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234121AbhHIT7o (ORCPT ); Mon, 9 Aug 2021 15:59:44 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mDBOU-009LTu-ST; Mon, 09 Aug 2021 19:57:06 +0000 Date: Mon, 9 Aug 2021 19:57:06 +0000 From: Al Viro To: Shoaib Rao Cc: Dmitry Vyukov , syzbot , andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org, christian.brauner@ubuntu.com, cong.wang@bytedance.com, daniel@iogearbox.net, davem@davemloft.net, edumazet@google.com, jamorris@linux.microsoft.com, john.fastabend@gmail.com, kafai@fb.com, kpsingh@kernel.org, kuba@kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, netdev@vger.kernel.org, shuah@kernel.org, songliubraving@fb.com, syzkaller-bugs@googlegroups.com, yhs@fb.com Subject: Re: [syzbot] BUG: sleeping function called from invalid context in _copy_to_iter Message-ID: References: <0000000000006bd0b305c914c3dc@google.com> <0c106e6c-672f-474e-5815-97b65596139d@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 09, 2021 at 12:16:27PM -0700, Shoaib Rao wrote: > > On 8/9/21 11:06 AM, Dmitry Vyukov wrote: > > On Mon, 9 Aug 2021 at 19:33, Shoaib Rao wrote: > > > This seems like a false positive. 1) The function will not sleep because > > > it only calls copy routine if the byte is present. 2). There is no > > > difference between this new call and the older calls in > > > unix_stream_read_generic(). > > Hi Shoaib, > > > > Thanks for looking into this. > > Do you have any ideas on how to fix this tool's false positive? Tools > > with false positives are order of magnitude less useful than tools w/o > > false positives. E.g. do we turn it off on syzbot? But I don't > > remember any other false positives from "sleeping function called from > > invalid context" checker... > > Before we take any action I would like to understand why the tool does not > single out other calls to recv_actor in unix_stream_read_generic(). The > context in all cases is the same. I also do not understand why the code > would sleep, Let's assume the user provided address is bad, the code will > return EFAULT, it will never sleep, if the kernel provided address is bad > the system will panic. The only difference I see is that the new code holds > 2 locks while the previous code held one lock, but the locks are acquired > before the call to copy. > > So please help me understand how the tool works. Even though I have > evaluated the code carefully, there is always a possibility that the tool is > correct. Huh??? What do you mean "address is bad"? "Address is inside an area mmapped from NFS file". And it bloody well will sleep on attempt to read the page. You should never, ever do copy_{to,from}_user() or equivalents while holding a spinlock, period.