Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3055239pxt; Mon, 9 Aug 2021 15:56:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFjxGVkBVaCeSkilO/6CFC9BcwjrKVDNSfy8gUtwSKcdjpLokd/Y5cbe7uDheMoDdcmabv X-Received: by 2002:a92:d84f:: with SMTP id h15mr101732ilq.12.1628549777168; Mon, 09 Aug 2021 15:56:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628549777; cv=none; d=google.com; s=arc-20160816; b=Mjr2PR1wFB5bBt4YBRBlc7KRTPVRXFH+OZNuvaFulbYiAh0axWK2UKrhk2sGnaltHc fGWWpxFw0MM8GqbHLzGjuwPJJhzdJBNvsfRyTdmhNaCBcgfFM+OOvsFP8rMPhNo4iIAH JCcrXnnxi3J7ESrbxfFV42Y0hU1Hkpd0Zq+vOcOyUL1tvwGhwrbDF/0utpyd+kxVSntF wLpeV6Jb0wu5liRV/oBzBXfJA6A6ooMo6ZDiDD0ljJuSH/IMIOKdVcumI9lbUG03LbML XXDOn8I1EfGpWZkST1qasr40nEk9kXXM6KZJ9H2nu5jFdJEBgiWbhGHjLUz3Rt4bHdGC wXNg== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ldrfAzt+82D7U95mAOhfaPxvFL6HFOr5TTzDkUPwPBo=; b=YR5TOvaxTIX3ideAKwp1h9779VrBnURvRnqYvGIJBMkLhv24XsgauQDTXvgB/SVQ/l 3d1a4+qnBlTk14issBAhifRGqCGdZiVznPdKy6BTg1AdUvbd+uwCgV1ZMjieVRGNaL5G efOKyKNLvz5rcpYpPFSrVqu+AWP8Sp84kagkfIfWGc7LPbHcqrplyXPxWxo6wfb12zrF QIZbQ+X1oVAqo0V/FDnI32ivcXHh3f+Gw8tqlG2J5PhSAxw6Arc26SjBq6SuMQEbJYk/ 0cfgQag1WLOev0e/FOx8s0RIor4U4n/7Zq2UQmQxzuVchEJ8JqmW8t9xJSBEd4noRAwS sjgg== 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 d17si19772607ilf.150.2021.08.09.15.56.05; Mon, 09 Aug 2021 15:56:17 -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 S235527AbhHIURB (ORCPT + 99 others); Mon, 9 Aug 2021 16:17:01 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:59044 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231127AbhHIURB (ORCPT ); Mon, 9 Aug 2021 16:17:01 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mDBhJ-009Lr8-Ed; Mon, 09 Aug 2021 20:16:33 +0000 Date: Mon, 9 Aug 2021 20:16:33 +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> <2901262f-1ba7-74c0-e5fc-394b65414d12@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 09, 2021 at 08:04:40PM +0000, Al Viro wrote: > On Mon, Aug 09, 2021 at 12:40:03PM -0700, Shoaib Rao wrote: > > > Page faults occur all the time, the page may not even be in the cache or the > > mapping is not there (mmap), so I would not consider this a bug. The code > > should complain about all other calls as they are also copying? to user > > pages. I must not be following some semantics for the code to be triggered > > but I can not figure that out. What is the recommended interface to do user > > copy from kernel? > > What are you talking about? Yes, page faults happen. No, they > must not be triggered in contexts when you cannot afford going to sleep. > In particular, you can't do that while holding a spinlock. > > There are things that can't be done under a spinlock. If your > commit is attempting that, it's simply broken. ... in particular, this +#if IS_ENABLED(CONFIG_AF_UNIX_OOB) + mutex_lock(&u->iolock); + unix_state_lock(sk); + + err = unix_stream_recv_urg(state); + + unix_state_unlock(sk); + mutex_unlock(&u->iolock); +#endif is 100% broken, since you *are* attempting to copy data to userland between spin_lock(&unix_sk(s)->lock) and spin_unlock(&unix_sk(s)->lock). You can't do blocking operations under a spinlock. And copyout is inherently a blocking operation - it can require any kind of IO to complete. If you have the destination (very much valid - no bad addresses there) in the middle of a page mmapped from a file and currently not paged in, you *must* read the current contents of the page, at least into the parts of page that are not going to be overwritten by your copyout. No way around that. And that can involve any kind of delays and any amount of disk/network/whatnot traffic. You fundamentally can not do that kind of thing without giving the CPU up. And under a spinlock you are not allowed to do that. In the current form that commit is obviously broken.