On Wed, Jul 20, 2022 at 09:47:29AM -0700, Stanislav Fomichev wrote:
> Syzkaller found a problem similar to d1a6edecc1fd ("bpf: Check
> attach_func_proto more carefully in check_return_code") where
> attach_func_proto might be NULL:
>
> RIP: 0010:check_helper_call+0x3dcb/0x8d50 kernel/bpf/verifier.c:7330
> do_check kernel/bpf/verifier.c:12302 [inline]
> do_check_common+0x6e1e/0xb980 kernel/bpf/verifier.c:14610
> do_check_main kernel/bpf/verifier.c:14673 [inline]
> bpf_check+0x661e/0xc520 kernel/bpf/verifier.c:15243
> bpf_prog_load+0x11ae/0x1f80 kernel/bpf/syscall.c:2620
>
> With the following reproducer:
>
> bpf$BPF_PROG_RAW_TRACEPOINT_LOAD(0x5, &(0x7f0000000780)={0xf, 0x4, &(0x7f0000000040)=@framed={{}, [@call={0x85, 0x0, 0x0, 0xbb}]}, &(0x7f0000000000)='GPL\x00', 0x0, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, 0x2b, 0xffffffffffffffff, 0x8, 0x0, 0x0, 0x10, 0x0}, 0x80)
Only BPF_PROG_TYPE_CGROUP_* (and the new lsm_cgroup) can get to
the set_retval func proto. I thought all BPF_PROG_TYPE_CGROUP_* has enforced
expected_attach_type. It turns out not true for BPF_PROG_TYPE_CGROUP_DEVICE and
BPF_PROG_TYPE_CGROUP_SYSCTL.
Acked-by: Martin KaFai Lau <kafai@xxxxxx>
