Received-SPF: pass (google.com: domain of linux-kernel+bounces-132913-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 5 Apr 2024 12:35:53 +0100
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	syzbot <syzbot+186522670e6722692d86@syzkaller.appspotmail.com>,
	LKML <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	bpf <bpf@vger.kernel.org>
Subject: Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in
 copy_from_kernel_nofault (2)
Message-ID: <Zg/iGQCDKa9bllyI@shell.armlinux.org.uk>
References: <000000000000e9a8d80615163f2a@google.com>
 <20240403184149.0847a9d614f11b249529fd02@linux-foundation.org>
 <CAADnVQ+meL1kvXUehDT3iO2mxiZNeSUqeRKYx1C=3c0h=NSiqA@mail.gmail.com>
 <Zg_aTFoC2Pwakyl1@FVFF77S0Q05N>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Zg_aTFoC2Pwakyl1@FVFF77S0Q05N>
Sender: Russell King (Oracle) <linux@armlinux.org.uk>

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 <akpm@linux-foundationorg> wrote:
> > >
> > > On Mon, 01 Apr 2024 22:19:25 -0700 syzbot <syzbot+186522670e6722692d86@syzkaller.appspotmail.com> 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!