From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BEF0CD11C2 for ; Fri, 5 Apr 2024 11:36:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAFF56B00B6; Fri, 5 Apr 2024 07:36:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B37F16B015C; Fri, 5 Apr 2024 07:36:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D83F6B015D; Fri, 5 Apr 2024 07:36:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7909C6B00B6 for ; Fri, 5 Apr 2024 07:36:06 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3D0288111B for ; Fri, 5 Apr 2024 11:36:06 +0000 (UTC) X-FDA: 81975274332.10.2FFCF92 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf11.hostedemail.com (Postfix) with ESMTP id 0A8DA40005 for ; Fri, 5 Apr 2024 11:36:03 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=bfGUHewc; spf=none (imf11.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk"; dmarc=pass (policy=none) header.from=armlinux.org.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712316964; a=rsa-sha256; cv=none; b=WS4CYAlzsvjPePzWh1DnlwRv/KpG/eeE6dzePrUGT2mzQQev78+Yn66HrqoYirYH6bH+wC 6D8REaXuOdmZLZjC9U63FfgD/uewigA4Kp1n018egCfnIB4RW1wqTOgqU6g3jYBLrXT6TB mMNFrj1n9TqzfKGyCLdH/XOUViohDng= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=bfGUHewc; spf=none (imf11.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk"; dmarc=pass (policy=none) header.from=armlinux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712316964; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CJp1+BJnCHioQp+DU63SJcb4jsAzGQK2w3ccuNxWycw=; b=V6AlY+8N8WXnZ0OmN6NzsRcKBD7+1cFXQ9zCvVcSktBhgowsXcJcJmu4bP2jP7QvbBTuUA iBYfjPx1Ltiw1xXrgj5z2hkizUiWkDeh3WhWn3NLag9Z7AO4HNtT9CmiJ9/cY5BJcZKzFb 96T/LmgJ39The8CZfF/muOqmtMKe3yQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CJp1+BJnCHioQp+DU63SJcb4jsAzGQK2w3ccuNxWycw=; b=bfGUHewcFdVduY14Pq0OjeGyw1 DpsgB0719rKoZwgF59u1emrB+ni9APzRlZR2mj7y3RKBu97MbBOryjmhDGg44GnsTDbdGV6Uo1qik gMTgK9hf8lR5Bk1FVdP7aFcANuQ8fXXJDJR6ShiGc78/M9oR5pGFeDYm545rHVubsTmIY8K9hUowr B7xj2sua2+QBBOykDkyQFwT9q01gGnnlrGP5GN8gD8l4I9a55He3umjnlmnp0nh6opemh9Rz0wEFe LelDLVkXUEi4seOr7CPtm1Gc+7SXKXPs1t7CbhMFAT1cln6K5F2pDghulJ0KwiAA9hDw2l6LubVoD 39s+mJMg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:53358) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rshrP-0002K6-1N; Fri, 05 Apr 2024 12:35:55 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rshrN-0001Lz-RJ; Fri, 05 Apr 2024 12:35:53 +0100 Date: Fri, 5 Apr 2024 12:35:53 +0100 From: "Russell King (Oracle)" To: Mark Rutland Cc: Alexei Starovoitov , Andrew Morton , linux-arm-kernel , syzbot , LKML , linux-mm , syzkaller-bugs , bpf Subject: Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault (2) Message-ID: References: <000000000000e9a8d80615163f2a@google.com> <20240403184149.0847a9d614f11b249529fd02@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 0A8DA40005 X-Stat-Signature: qyyumpsktpobri9f485x8ytrpcahgo7y X-Rspam-User: X-HE-Tag: 1712316963-689630 X-HE-Meta: U2FsdGVkX1/GGLqPnx+JEeyx8hoE0z35ycaKYX13HJyPb+a6M0OtoP3rsOdrC6Y0u6VZzvoEjzJer2t8HWTC2e9rHzG6prOUAQOlFTWylxS6UYUTSrcFS3FlxrOIsFvRVokmGoSjWcSTFjylNSfqGAiPik4tem4vBLh2NZkm5Aps4ypV0x7sYZkQjldvjKCm/1N1LhKLDQ9XVmmF95WYm/pYp5aeEEw0TfAuge+JS5AzL/bbxDdYD+IUU6BdpwlPSnPXEgnB1V3VB1K7B3J8K1GE0haarxtgibaj02HMy7yw8nfeFmuNXLmvjEk0eirVV+eSmXJCVIeULleB4nt4hjAWQyWgHgtq11v2w9XaCG9RAmoEVB+Xo+t+ODzAVvLktIQLB8/PWWkY2YSZaOBcCMlr37iUpNN8vB9sFxvovEClYQuf5s87Kxvj4n7kJVuD/50SW4Tw3JM+uyqd1DgcAUsKJ3CsF/BV9v7pSqyUKZEK77a8mMYeEJshe/pd/jK4cvGm2Rog9jgkKmks0/HGil3omJGE4bq2/AiQjsj9K328y8NtK0uekJr21INlaqDbyvRAjF/IA4Q9w0qIuPop5enVamZGR6fAfRtqgVhdDAtTCTBum6PtDftC4b3e0KEIG6180AQ/ZNfwk35HkM0gPcXCODHB5d5RBKianuaBgCc5gY7T4JOAKsDZJY8TuOebLGWOAbKE8qJxFLmkmOLAR10QI+LsPNla4BJ9qoUzR/IFpUVRg3op9OrcgPy+i6LgWrDkfqsHI/U6PJJp5ljOJj4W6b+4F/bPCMihe1aKIBVLqV1Bteh54pB2GR9ECSWwVOmYhKrL10LXjxmgKifSZbacOg0PROEyltTHOzaMlyAS2cjZBvz7PpMSGpvlN78YGsESYieNf0oH9CDAHVSjJKua2SpHFJzzDY/ey8Wp9R7hHdbb5QuEcrtTbxC30l4vrxrJ1UG+v2Krm5jsKJ7 +mcAPlI9 H4hCj+UmKKvNX9JJXrfCHmy21sOzN06vdX35Ok8ytqhvo/vl74X5G80a5bDgFu2X+aZk8iLyn0WiEYsLCucWUjPxH8lb0gxBV1fiEZgGSvTz5ClsqBlvcIzhgvzXp7UOAbhJnM79Gi7V+1AL9Xv0Qjn26LxQI1/dEqaAjasnhgFNr03eSdCtmpkqgARh9It/TfeiOoAQ/vVQ3RGmpT16rnD6aqwRoI+IR8IFhCHhcirE4Dm2Tcgzn33qoe2sAD8dRcDJDiC/k9z7YqMGm1sY4FP5QiwtVtILcyojykIy+I2S21tlsvhmUR33J83HlsT2ho1NN0M2/nReTxu+RqGs77Dq5PrjJKc3ctL7YnRml3HoLBK2wwCwrdmAZ+uO0MY6W+5zMuMIZqlytIFZox67Ynyg3rymNXqSKy1P6w2o6mlRg9Iin527KKRQWL5l3O5fLaYKVa5KaomtivaokPBW5gs1MfFSDQObc2EUxBYd34omc10FgsMflMtP/EpYWIVZByLbXDHAlOX8+zH4ma8KpQdYqXFBY5l57U8JSHZtQ7/LsxrUlyzAVVCOa44RX2jsIDDn1XZKVQDlLY97QlIQyuJ0+0RXmVjR4oYvlqy+r5YlcP/DIii1ftzX1KFttiJbgup6y/5r5QZYN13rvGAf27c9eSpTFY3rHqpu7aMymxIBs910dQNctecpgmysxSb3gqSSbI+v/Fz48Z6DFrrfW6oq+6EZUKoyn7DAtPeVrjR4hjDo9TEXTbbWAHw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.006311, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Apr 05, 2024 at 12:02:36PM +0100, Mark Rutland wrote: > On Thu, Apr 04, 2024 at 03:57:04PM -0700, Alexei Starovoitov wrote: > > On Wed, Apr 3, 2024 at 6:56 PM Andrew Morton wrote: > > > > > > On Mon, 01 Apr 2024 22:19:25 -0700 syzbot wrote: > > > > > > > Hello, > > > > > > Thanks. Cc: bpf@vger.kernel.org > > > > I suspect the issue is not on bpf side. > > Looks like the bug is somewhere in arm32 bits. > > copy_from_kernel_nofault() is called from lots of places. > > bpf is just one user that is easy for syzbot to fuzz. > > Interestingly arm defines copy_from_kernel_nofault_allowed() > > that should have filtered out user addresses. > > In this case ffffffe9 is probably a kernel address? > > It's at the end of the kernel range, and it's ERR_PTR(-EINVAL). > > 0xffffffe9 is -0x16, which is -22, which is -EINVAL. > > > But the kernel is doing a write? > > Which makes no sense, since copy_from_kernel_nofault is probe reading. > > It makes perfect sense; the read from 'src' happened, then the kernel tries to > write the result to 'dst', and that aligns with the disassembly in the report > below, which I beleive is: > > 8: e4942000 ldr r2, [r4], #0 <-- Read of 'src', fault fixup is elsewhere > c: e3530000 cmp r3, #0 > * 10: e5852000 str r2, [r5] <-- Write to 'dst' > > As above, it looks like 'dst' is ERR_PTR(-EINVAL). > > Are you certain that BPF is passing a sane value for 'dst'? Where does that > come from in the first place? It looks to me like it gets passed in from the BPF program, and the "type" for the argument is set to ARG_PTR_TO_UNINIT_MEM. What that means for validation purposes, I've no idea, I'm not a BPF hacker. Obviously, if BPF is allowing copy_from_kernel_nofault() to be passed an arbitary destination address, that would be a huge security hole. So I think BPF folk need to urgently state what checks are done on the destination value for _any_ function that BPF can call which writes to memory. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!