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 0C020C67861 for ; Tue, 9 Apr 2024 08:16:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EADE6B0092; Tue, 9 Apr 2024 04:16:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69B126B0093; Tue, 9 Apr 2024 04:16:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5631E6B0095; Tue, 9 Apr 2024 04:16:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 399D36B0092 for ; Tue, 9 Apr 2024 04:16:04 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E2E3F1202DD for ; Tue, 9 Apr 2024 08:16:03 +0000 (UTC) X-FDA: 81989285406.13.64E17FB Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf24.hostedemail.com (Postfix) with ESMTP id A18F118001B for ; Tue, 9 Apr 2024 08:16:01 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=Tkch436q; spf=none (imf24.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=1712650562; 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=RRSBY6/rtPwcAAaFW3HJTN9NeVlK6dzskGTvl9SWwlk=; b=YpzGrzRc2dct0cNOmE5tcS9QbGxZ1KZz24D6wTcFu7IDtxGAYItupDHnxI6SWaU/+8orEy zuRgywu9C5Tvj8LUrlDBXnb4qcS8dQpY4NqQlSxBCHQpK4VtlYLg6TBeG3/djnI4KFaLEU Nw/5wB8+di2SZ/HeKD3OC2ZlzFLGNiI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=Tkch436q; spf=none (imf24.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=1712650562; a=rsa-sha256; cv=none; b=bCs8wre1LR1Q9uHe2Us79bR6NMd1AYOirummn9jeiMLyet3xsUQtmFg6/srONm9p7CjHGo UXmk6qddiNk5aPjP9Ruqwg1vkq0bi/gJn32xegQlfc7PHBfilaQ5SOW++yLd1fnYOJEVjL 76SvmLgjqzrcHsitYlarinxs9Auz4+o= 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=RRSBY6/rtPwcAAaFW3HJTN9NeVlK6dzskGTvl9SWwlk=; b=Tkch436qG2RJnWFcSMxqYvcDnX KG41Odci/LVUbafwNby6jvXCU7pWNzdA7kTCzKMIXwBqhUsCZdJQ/m1WO7P1wwVr3UWL3FKQ84DTj 3Y0Nm7/Hb8z/7M+x6gGufi1w4MnaBd/4/kw/q8rIge2shXxnq0XNhUGsMBqnP7+8WgGYrD+R5O7RW NmzLSh2XxGZb86K7eqKxsrt/5DqkIIQfcns4vAJNATXV6HCg58Pn5e8GEpmAjVI2PqCA2s2GECvwP LzPvDC4wbDZCF//QQEu6xOkY4cHn4GnwTHJAMtx8aYcWFfb6kVs5yKlSvvAWZkkP7UAVJfivrERak 0CriE9Ug==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:38758) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1ru6dz-000640-0N; Tue, 09 Apr 2024 09:15:52 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1ru6dx-0004vn-Gs; Tue, 09 Apr 2024 09:15:49 +0100 Date: Tue, 9 Apr 2024 09:15:49 +0100 From: "Russell King (Oracle)" To: Puranjay Mohan Cc: Andrii Nakryiko , Alexei Starovoitov , Mark Rutland , 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-Queue-Id: A18F118001B X-Rspam-User: X-Stat-Signature: u9q3co9cyzgwz8ttn5xz95f5ysuabz3w X-Rspamd-Server: rspam01 X-HE-Tag: 1712650561-655775 X-HE-Meta: U2FsdGVkX1/Ecpnh9ud19zob5rQSXrVTc3jyazm7z93LJyPNoy/j6prugEiBEqpJd6bRN1RZdW3/R1AG/eixFdpZXVZ4UbUqLXggyNZiSoVLIszZxmIUKfNXL+HXVpgDxGr3hwVpb7iEVXO323YRBIhf/15jsjkfrDhLmdPdj07pLmf4NRsRh28Ou8uJCleP3Nq4q0FeqpHf2o6b2FwpZZakDcR9/gFERNaHI02SBDkP8mg1kJgi/raW6/EhreN1N0+iVZEIHhJw8VnCitpUvwkuhR0o6EgK/T0Gg83SmUA0hHmwzpy9Y1hcd+d0fnDEcB4S2Fego16WsCN7QHUB4JL+NCOtAVPDtKXSsw+v5qklH3wPcUHjuCkwJiig0b5YpFrWgDVv5m/VK3xPQUeUUWKKKLaRpSUrjZlx/+jbQG0NZBJqOfP6OBtMRPbwUeEI1nmFPzXDObe7LxtBfNdFpXG7HGokm888KEEItyjcrOpZBbGkGlYRUm5FhKxkRO1VrLX/aG1F9u8iZ1UIHa8UDly/XAS2Q3hb1k4kB9i3FIV60vAdC/53gGh0PdCmMA3BPtjnrjA5gwF2u7kVIyecKInvSpyeGpQTWWNlQSkbRUL7qj9Joye5n5HqUifyAgjhlgzztAsRnzqJYJeH6pitcr9Qedc3SzoLqF6JnersLBI4iNaACeEFE3POvmD3Ek4A6S0F3uGe5m3N2e+l/5mAxWgAWULTS6xOCARNtSS0cR8tctPUoje7b95nMVqSmIxL49X1Xt9hvbNgl6KWIE+eSEdx/lbPfQxkQsNfXm2uNYjablK3nzfe0KiEgyvg7vcGoTF28klGFeHPLAtRiTZzXZqkdQbd3atNRslGqU63WuedVB/Vwxu28Gg3YtU9JLHhoSrw5OL1dFpug7mWdL8D2qL3+AZY/ijNHUzUELftFRnvbdhKx8ORw2CgB5JiBDL/puSPNpMoJk8WuEhp6Dq jpV5VQEd jy+azGfer6Bz9GWhfsVrP0NukGah+GSigj0LZEzQRp1sWkwhpQTvbcXdzgEH0INNA5etiffImf+OP6zbcbthdxbwwpm2bX1f67+N/YCwYsnqL/yx9i57155b/boR9UVMROkNdlT3B1YCvyqsXxOYnwRchb0XpOksowI6res0Uq5+gHa02RQ6JCt6fecuhRi5nsAUZaDxU6gwgvLKF1TAsPOTEPRxcuxxk5qW74MU2Kp/xfMMLAgRMbSehzvCB1nqFccQ0PVeIsTUtpTIL30KCy5l6KceAfLG6K4iOAkcQ7gx5bUSqH4LIAlLfpVS1ffcIj+k1VV5yzU59Nas7DC7LCQ91EhvZ1KYxjg4k12AU/3pdF3ICOtKCV/hTT3eqB4b3vUbw0JlzMbs3zyNzAAuuZBzraciuEXhwk442UzCaH6FeuIq9TVn+yVP2m0j9qeYXC2PWFlQenBwqZFgLzfF9TbrXvXSJhCxu0CxBJY2iUsRSe/1RpZQPtV8Yj5kmw1ViOo8Y+4/ommH3eFj2D/hsSiBwe98xq8OXx8BCKChOtAh8U5t3QZRkuNKVKsvD63Q9SYvpfwq4CPJR0hHDsAKb+ykUghh0ddBR2H6oH7sKHHqqUrDtdeReU9tIHrlzKZBVcaW6vht1OlOCNCChl+G+r81Bs/SjuoSHUjvEiegmrvwHOFEUd1GQz/uqDcC4FctIwz0vrB1oTEMU972GCZM4LLxrYJl1ZssKXMkEnA8Nuix+RkvwYvad4kXX1Ur4U7SMsLlDXgZjSI83R+XAXEKEAmZdgQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000067, 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 Tue, Apr 09, 2024 at 07:45:54AM +0000, Puranjay Mohan wrote: > "Russell King (Oracle)" writes: > > > On Fri, Apr 05, 2024 at 10:50:30AM -0700, Andrii Nakryiko wrote: > >> On Fri, Apr 5, 2024 at 9:30 AM Alexei Starovoitov > >> wrote: > >> > > >> > On Fri, Apr 5, 2024 at 4:36 AM Russell King (Oracle) > >> > wrote: > >> > > > >> > > 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. > >> > > >> > If that's the case that's indeed a giant security hole, > >> > but I doubt it. We would be crashing other archs as well. > >> > I cannot really tell whether arm32 JIT is on. > >> > If it is, it's likely a bug there. > >> > Puranjay, > >> > could you please take a look. > >> > > >> > >> I dumped the BPF program that repro.c is loading, it works on x86-64 > >> and there is nothing special there. We are probe-reading 5 bytes from > >> somewhere into the stack. Everything is unaligned here, but stays > >> within a well-defined memory slot. > >> > >> Note the r3 = (s8)r1, that's a new-ish thing, maybe bug is somewhere > >> there (but then it would be JIT, not verifier itself) > >> > >> 0: (7a) *(u64 *)(r10 -8) = 896542069 > >> 1: (bf) r1 = r10 > >> 2: (07) r1 += -7 > >> 3: (b7) r2 = 5 > >> 4: (bf) r3 = (s8)r1 > >> 5: (85) call bpf_probe_read_kernel#-72390 > > > > I have started looking into this, the issue only reproduces when the JIT > is enabled. With the interpreter, it works fine. > > I used GDB to dump the JITed BPF program: > > 0xbf00012c: push {r4, r5, r6, r7, r8, r9, r11, lr} > 0xbf000130: mov r11, sp > 0xbf000134: mov r3, #0 > 0xbf000138: sub r2, sp, #80 @ 0x50 > 0xbf00013c: sub sp, sp, #88 @ 0x58 > 0xbf000140: strd r2, [r11, #-64] @ 0xffffffc0 > 0xbf000144: mov r2, #0 > 0xbf000148: strd r2, [r11, #-72] @ 0xffffffb8 > 0xbf00014c: mov r2, r0 > 0xbf000150: movw r8, #9589 @ 0x2575 > 0xbf000154: movt r8, #13680 @ 0x3570 > 0xbf000158: mov r9, #0 > 0xbf00015c: ldr r6, [r11, #-64] @ 0xffffffc0 > 0xbf000160: str r8, [r6, #-8] > 0xbf000164: str r9, [r6, #-4] > 0xbf000168: ldrd r2, [r11, #-64] @ 0xffffffc0 > 0xbf00016c: movw r8, #65529 @ 0xfff9 > 0xbf000170: movt r8, #65535 @ 0xffff > 0xbf000174: movw r9, #65535 @ 0xffff > 0xbf000178: movt r9, #65535 @ 0xffff > 0xbf00017c: adds r2, r2, r8 > 0xbf000180: adc r3, r3, r9 > 0xbf000184: mov r6, #5 > 0xbf000188: mov r7, #0 > 0xbf00018c: strd r6, [r11, #-8] > 0xbf000190: ldrd r6, [r11, #-16] Up to this point, it looks correct. r2/r3 contain the stack pointer which corresponds to the instruction at "2:" > 0xbf000194: lsl r2, r2, #24 > 0xbf000198: asr r2, r2, #24 > 0xbf00019c: str r2, [r11, #-16] This then narrows the 64-bit pointer down to just 8!!! bits, but this is what the instruction at "4:" is asking for. However, it looks like it's happening to BPF's "r1" rather than "r3" and this is probably where the problem lies. I haven't got time to analyse this further this morning - I'm only around sporadically today. I'll try to look deeper at this later on. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!