On Mon, Feb 12, 2024 at 3:42 PM Kumar Kartikeya Dwivedi
<memxor@xxxxxxxxx> wrote:
>
> On Tue, 13 Feb 2024 at 00:34, Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > On Mon, Feb 12, 2024 at 3:16 PM Ignat Korchagin <ignat@xxxxxxxxxxxxxx> wrote:
> > >
> > > [288931.217143][T109754] CPU: 4 PID: 109754 Comm: bpftrace Not tainted
> > > 6.6.16+ #10
> >
> > ...
> > > [288931.217143][T109754] ? copy_from_kernel_nofault+0x1d/0xe0
> > > [288931.217143][T109754] bpf_probe_read_compat+0x6a/0x90
> > >
> > > And Jakub CCed here did it for 6.8.0-rc2+
> >
> > I suspect something is broken in your kernels.
> > Above is doing generic copy_from_kernel_nofault(),
> > so one should be able to crash the kernel without any bpf.
> >
> > We have this in selftests/bpf:
> > __weak noinline struct file *bpf_testmod_return_ptr(int arg)
> > {
> > static struct file f = {};
> >
> > switch (arg) {
> > case 1: return (void *)EINVAL; /* user addr */
> > case 2: return (void *)0xcafe4a11; /* user addr */
> > case 3: return (void *)-EINVAL; /* canonical, but invalid */
> > case 4: return (void *)(1ull << 60); /* non-canonical and invalid */
> > case 5: return (void *)~(1ull << 30); /* trigger extable */
> > case 6: return &f; /* valid addr */
> > case 7: return (void *)((long)&f | 1); /* kernel tricks */
> > default: return NULL;
> > }
> > }
> > where we check that extables setup by JIT for bpf progs are working correctly.
> > You should see the kernel crashing when you just run bpf selftests.
>
> I agree, this appears unrelated to BPF since it is happening when
> using copy_from_kernel_nofault (which should be jumping to the Efault
> label instead of the oops), but I think it's not specific to some
> custom kernel. I can reproduce it on my dev machine on top of bpf-next
> as well, and another machine with Ubuntu's generic 6.5 kernel for
> 24.04. And I think Ignat tried it on the mainline 6.8-rc2 as well.
Then it must be vsyscall address that this series are fixing:
https://patchwork.kernel.org/project/netdevbpf/patch/20240202103935.3154011-3-houtao@xxxxxxxxxxxxxxx/
We're still waiting on x86 maintainers to ack them.
