Received-SPF: pass (google.com: domain of linux-kernel+bounces-133439-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <000000000000e9a8d80615163f2a@google.com> <20240403184149.0847a9d614f11b249529fd02@linux-foundation.org>
 <CAADnVQ+meL1kvXUehDT3iO2mxiZNeSUqeRKYx1C=3c0h=NSiqA@mail.gmail.com>
 <Zg_aTFoC2Pwakyl1@FVFF77S0Q05N> <Zg/iGQCDKa9bllyI@shell.armlinux.org.uk> <CAADnVQ+LKO2Y90DVZ4qQv3dXyuWKkvFqqJ0E_p_=qwscsvnaVg@mail.gmail.com>
In-Reply-To: <CAADnVQ+LKO2Y90DVZ4qQv3dXyuWKkvFqqJ0E_p_=qwscsvnaVg@mail.gmail.com>
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Date: Fri, 5 Apr 2024 10:50:30 -0700
Message-ID: <CAEf4BzYNc-cxRu9qEe2DWdCBNwXAvpSBHKtUhXtoEhB_XNc1Gg@mail.gmail.com>
Subject: Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in
 copy_from_kernel_nofault (2)
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>, Puranjay Mohan <puranjay12@gmail.com>, 
	Mark Rutland <mark.rutland@arm.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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 5, 2024 at 9:30=E2=80=AFAM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Apr 5, 2024 at 4:36=E2=80=AFAM Russell King (Oracle)
> <linux@armlinux.org.uk> 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=E2=80=AFPM Andrew Morton <akpm@linux-fo=
undationorg> wrote:
> > > > >
> > > > > On Mon, 01 Apr 2024 22:19:25 -0700 syzbot <syzbot+186522670e67226=
92d86@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 readi=
ng.
> > >
> > > 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 th=
e report
> > > below, which I beleive is:
> > >
> > >      8: e4942000        ldr     r2, [r4], #0  <-- Read of 'src', faul=
t 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 doe=
s 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 =3D (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) =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
   6: (b7) r0 =3D 0
   7: (95) exit