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 D84F0C67861 for ; Tue, 9 Apr 2024 10:03:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 712B36B0088; Tue, 9 Apr 2024 06:03:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C33C6B0089; Tue, 9 Apr 2024 06:03:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58B5B6B008A; Tue, 9 Apr 2024 06:03:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3ABE46B0088 for ; Tue, 9 Apr 2024 06:03:32 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BA0FC8035A for ; Tue, 9 Apr 2024 10:03:31 +0000 (UTC) X-FDA: 81989556222.09.1C873C1 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf10.hostedemail.com (Postfix) with ESMTP id A9CFEC0025 for ; Tue, 9 Apr 2024 10:03:29 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LbIU5Jvj; spf=pass (imf10.hostedemail.com: domain of puranjay12@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=puranjay12@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712657009; h=from:from: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=VjADMTPZqcstz8lVC2gm5IpQDMR3KXmVjspn4JhSPv0=; b=o/Sb9iGiFbSpiroLsbJMzOhNeC+CLHkEx3W2RoN4tQHqGSD0M/+QX2GP0cRgQphlWKaREw Li5DGeI3KscV8x4r2vMPEjoTt68wo/4G5H3Y4a0HMCEQW3VopX9hrBvpxZ83leSolKc9Zg is9TjK+vBYWsm1aivcOZ3zj/GiwYsQA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712657009; a=rsa-sha256; cv=none; b=jxYDeKOr/Jk0Hbayi3YoYXbEL79Ywi9+Hu0CVzkt5e3F98uGc12dQlLj8xVJNt3qRXz2c8 MF3n5DU9yEmopuKHy3M8/LKlNWfbg/LiJQ7N2IK6yTYwXGbV109Mf6B43fVZXMn0HCi8gi 5RyxqtmNveCRr5yERYUK3AzI0qK+TGE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LbIU5Jvj; spf=pass (imf10.hostedemail.com: domain of puranjay12@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=puranjay12@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-416b66163a9so1453555e9.2 for ; Tue, 09 Apr 2024 03:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712657008; x=1713261808; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=VjADMTPZqcstz8lVC2gm5IpQDMR3KXmVjspn4JhSPv0=; b=LbIU5JvjwcVAzBMEQ2eMnOLnWVxCLeCwiBQP/Uf1+jPjQreM6d6QyFF0qTdWtKf5KZ 1TvFYK79zZhRm0zzznueZoV8vYdxqLnqP1GMLVgRTi8z4eo0cV712S1dMhQkuwQ9OCFS KF9Ivye3NDrZp0rb22p86awVK/oDyxqg6rOkyOhFTdjlsX3R5S7+k3vPkRP5eGxRyO9L 4/FKy976+yM/fdxyvCNMZG3RClhs0zrJE/NzfPsz+I7RnxhSr29qtaHc1mqg9I8x8ZXK 1DLQ8hI5on8amMH1xoP3CBbk/TL0ZKGoXEKbTOhZWfHvkGanIGDjFRhlRZcwIb3S5PIm 5Zkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712657008; x=1713261808; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VjADMTPZqcstz8lVC2gm5IpQDMR3KXmVjspn4JhSPv0=; b=r+Mhv8uf4imNCrwVxfcz0usBFtxY+TJOPOIVRSEC4xx0Tdbuo/wv/EC2RzI1JRkq1l xDXrs9xJEtLUNXdMv+DX8bsA1krHbNLj4CBEsEPJ7lcfT1Q338t8SLPzezQHT7Hu+4sj /12/Hq/eI8Nzaz/PHh7d37hbvoqR5VIr9BDRuO7Or+fRgHbRTFlN6QYbX98M3VmsvT6s a4Btc0dKS/vs+Xwgc9/GpbYuS/XSi1OJ/5jigdBvfdHdrEziyT54bLP8RjGvd8oYixFk ZPUsr3gYIqa3177WqlofwhwUV2TjHwtR0gR3Am3/mZ5gnyk7OBo0W1LrB+/InmoAIMLM dxdA== X-Forwarded-Encrypted: i=1; AJvYcCUPg2Zt4NpcJFI+9jslhdu7J7t3r2JqoP1U1SlDA8uw/jJPwDDeWhXb6BN6Umu9WODiOJqCPtBe7Z+B90AB8icG+zc= X-Gm-Message-State: AOJu0YzwcLV10ARnL6d0O8S4wREV5krscrWr/frwSoubiWXJ0U4zcMXa VezdZo7zHuIBfIZhx7+BIppjS1e1J2tQM862MP7XZS0FS3fBgyQvLNaeZi1YIqp3Dg== X-Google-Smtp-Source: AGHT+IFRgJDyiXvcoHUn5ECDGcIlw7ghQjN+ItwK0q590NBLs0v9v5Kf2Zqi2OSo/0F9WOd+9CIqSQ== X-Received: by 2002:a05:600c:19d1:b0:416:8efd:1645 with SMTP id u17-20020a05600c19d100b004168efd1645mr3810151wmq.7.1712657007887; Tue, 09 Apr 2024 03:03:27 -0700 (PDT) Received: from localhost (54-240-197-231.amazon.com. [54.240.197.231]) by smtp.gmail.com with ESMTPSA id u10-20020a05600c19ca00b0041632fcf272sm14159656wmq.22.2024.04.09.03.03.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2024 03:03:27 -0700 (PDT) From: Puranjay Mohan To: syzbot Cc: Andrii Nakryiko , Alexei Starovoitov , Mark Rutland , Andrew Morton , linux-arm-kernel , "Russell King (Oracle)" , LKML , linux-mm , syzkaller-bugs , bpf Subject: Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault (2) In-Reply-To: References: <000000000000e9a8d80615163f2a@google.com> <20240403184149.0847a9d614f11b249529fd02@linux-foundation.org> Date: Tue, 09 Apr 2024 10:03:01 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A9CFEC0025 X-Rspam-User: X-Stat-Signature: oa86xkxf6q98yf7495y9gjejyh5fsyn5 X-Rspamd-Server: rspam03 X-HE-Tag: 1712657009-826051 X-HE-Meta: U2FsdGVkX1/8kc+ruPp/7FJxA5THHI1oz68vkyVhhwuUdGN04VhVjvfTpDGGpear19ixEB9U2/7fbWeckAXM/MD5LYn3OZ3zGMXj6ejwDb3mqsrGxKAfFcaCile7DBCCO9Ld7SZEx2uF/kTHP6QnwrAPm04Dqw08ye72c5uM63vuv8u/aw/u7G66798LdlPZf8H12guBRRkcBQ2rF/sIkFY+Jr3eVBI9s0gRNUwHnVyzmveJKdGOFxvKWyGUX8G1BZFxlw8dA1Jaui+6ZHZnXHed/c6y6U4ORgMaDsPEm6RLiHyeboZQBxtqY1n5buz6c3rXEiH7It1UXlR9TlPU25MjP/RlDtKwzPidq8C+87crLaUvKIlj92cXOSfsIlXEFroE6gzSDTWlhdTU4Yh9V6BdlURsyFeZT1DLL8huX5uyv2TXAMAZQOENntNq4zncovg/8qvRz4edRFbB8t8a/JtxkK7AMrQCPuERmquLeJchMc4QHZ8Ym2NbqSHo71uxHWoerglkRH3MLEOYebWubCaNNkPi4be1JN9i5ba6ucYq+gvFMFrZWvsDl0klWuMv1Ap+U8H78DwNB1ZiVFGgnPg2SzmGOFnSQVErk+ecrsEo/1iARdJZe0cmjcymjDf4rogOxZ36+obd+C7mZsEzH/jsm6ATsVjwo5bNxp0jX4GWiyM4QUH/e9Ps6I1fXze/3UBeDaLL3pZ8u5n1sOVijEIuqoUbjth4zw4xcVDIcfe0wpkda7KK8D1/WZ7iDyMmNX1kL8mnOvYOyJ4WB/z931/r/kyL4cm7XHtp+g/tQCEsetqpk1JqD7DI6q/2h9Vmz4Ew4Yh28HIug2+tjlHJBR0BTf1gyXwsIdwW1j6Y+dneB69JYoBG1r4ByEgkfOFe2St9jcXuVhndvvDhPqpog/X1W0jPaJsKu19qTwWyuf6ZPg6L9CCvXr9tWw/RL5h6N5ZuHZVMdESRmOCuHmw hhLaSQHz /ZTMsG2y34WI9gSWWoF7W/IjBcf5RCVZKZ8UIoLoXY7Ngd9n7jKrtMXcOW6Mbj4RTtp7UkBrMC3Z/18lxDY5X95h9HHnOzy0R9w4Lo4OA0KpXT5JtrWTKJx3zh//IU7K9cBijWvdf7vqUXez1ycx8FpVmMX8wYBjW0Cl9AtMc7KkuQAX2eAb+AiB3mCr1PFs0K8WUIiMLwsaU+ytW8uNk8O58W4B0M/a/Ps5H7Y42VKTPFgwXRacAl2gqlNX4oy1bCDvRIE3Z2NS7qBN2fqNUKRuR0oFpeJ6ISfqiuDL6eCB3Laxznd9C+NjJB7D46RIzHLTal/4xTGoe1YcN2eH/gPWptU0K9izndVU7t6LlZe8Yc661WYDdjjXbWNtnP/gfK0wJbPiw07EnQTiMtlQeXn9DzIQ+j7VG8dyriZiZcK2ibZOXYazrv/CRI/E34rHAK5EJDTAodw+KEu8rka3sMnTMpKY4YUcMukAgweTw7Kr8hy7C3kjdD9mOWqN0IKz5ZdCa5uC/NSV+55UWOA6P8fUal6lR+cIZE2Zl9DTTv32U9qLTXtF9YbGl+K4J51/MNbUdwxri2HKvA4a/h1ZwxG2TT4ObSxWi+j+25ZPQFIIiNdrS68xYC7ilLoPR75SyD0jUHDXWiF2nzmHOKfXNo4rv67GQvb04YTW48Fw8jLVfcGK7YGPX0MAKPr4ZF2VXehhB2HyhPoKvGL0t3gQMGGHwhUHaZeh4DZql2AKsEHEvETuMeDALz73+Q2CS/0x8AbfxM8NTYlkVy6FdYGRBYlrllxhHYbue2SeLz2JLp36WV4YemFztadqbE3D5EdoIbbVyIjwENkf9ZJtJ11LOU86vwzg2vdpPRTEKWXGHZbwXPYQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: "Russell King (Oracle)" writes: > On Tue, Apr 09, 2024 at 07:45:54AM +0000, Puranjay Mohan wrote: >> "Russell King (Oracle)" writes: >>=20 >> > On Fri, Apr 05, 2024 at 10:50:30AM -0700, Andrii Nakryiko wrote: >> >> On Fri, Apr 5, 2024 at 9:30=E2=80=AFAM Alexei Starovoitov >> >> wrote: >> >> > >> >> > On Fri, Apr 5, 2024 at 4:36=E2=80=AFAM 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 wr= ote: >> >> > > > > On Wed, Apr 3, 2024 at 6:56=E2=80=AFPM 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'? Whe= re does that >> >> > > > come from in the first place? >> >> > > >> >> > > It looks to me like it gets passed in from the BPF program, and t= he >> >> > > "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 pa= ssed >> >> > > an arbitary destination address, that would be a huge security ho= le. >> >> > >> >> > 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. >> >> > >> >>=20 >> >> 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. >> >>=20 >> >> Note the r3 =3D (s8)r1, that's a new-ish thing, maybe bug is somewhere >> >> there (but then it would be JIT, not verifier itself) >> >>=20 >> >> 0: (7a) *(u64 *)(r10 -8) =3D 896542069 >> >> 1: (bf) r1 =3D r10 >> >> 2: (07) r1 +=3D -7 >> >> 3: (b7) r2 =3D 5 >> >> 4: (bf) r3 =3D (s8)r1 >> >> 5: (85) call bpf_probe_read_kernel#-72390 >> > >>=20 >> I have started looking into this, the issue only reproduces when the JIT >> is enabled. With the interpreter, it works fine. >>=20 >> I used GDB to dump the JITed BPF program: >>=20 >> 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. > > --=20 > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! I found the problem. The implementation of Sign extended move is broken, it clobbers the source register. I have sent a patch to fix it and also fixed another issue that I saw: https://lore.kernel.org/bpf/20240409095038.26356-1-puranjay@kernel.org/ I have manually tested with the reproducer but let's try to rerun the reproducer through syzbot: #syz test: https://github.com/puranjaymohan/linux.git arm32_movsx_fix