[BUG] bpf: kprobe_multi allows BPF_F_SLEEPABLE programs, causing sleeping-in-atomic splat

[Varun R Mallya]

Hi,

I found a bug in the kprobe_multi BPF link creation path where the kernel
fails to reject programs with BPF_F_SLEEPABLE set.

kprobe.multi programs run in an atomic/RCU context and cannot sleep.
However, bpf_link_create() with BPF_TRACE_KPROBE_MULTI does not validate
whether the program being attached has BPF_F_SLEEPABLE set. This allows
sleepable helpers such as bpf_copy_from_user() to be invoked from a
non-sleepable context, triggering a "sleeping function called from invalid
context" splat.

Reproducer:

  /* crash.bpf.c */
  SEC("kprobe.multi")
  int handle_kprobe_multi_crash(struct pt_regs *ctx)
  {
      char buf[16];
      int ret;
      ret = bpf_copy_from_user(buf, sizeof(buf), (void *)ctx->sp);
      bpf_printk("bpf_copy_from_user ret: %d\n", ret);
      return 0;
  }

  /* loader: manually set BPF_F_SLEEPABLE before load, then attach via
     bpf_link_create() with BPF_TRACE_KPROBE_MULTI */
  bpf_program__set_flags(prog, BPF_F_SLEEPABLE);

Kernel output (bpf-next 7.0.0-rc5+):

[  483.577248] BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:
169
[  483.577364] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo
[  483.577420] preempt_count: 1, expected: 0
[  483.577453] RCU nest depth: 2, expected: 0
[  483.577486] INFO: lockdep is turned off.
Attachment successful! The bug is confirmed.
Check 'sudo dmesg -w' for BPF prints and warnings.
Triggering v[  483.577569] CfsPU: 7 UID: 0 PID: 1787 Comm: sudo Tainted: G        W           _
rea7.0.0-rc5+ #4 PREEMPT(full) 
d[  483.577571] T.ainted: [W]=WARN..

Su[  483.577572] Hrvardware name: Bochs Bochs, BIOS iBochs 01/01/2011v
[  483.577573] Call Trace:
[  483.577575]  e<TASK>
[  483.577578]  d!dump_stack_lvl+0x54/0x70
 [  483.577582]  If __might_resched+b0x200/0x220
p[  483.577585]  f__might_fault+0x_c2c/0x80
o[  483.577587]  p_copy_from_user+y0x23/0x80
_[  483.577591]  bpf_copy_from_user+0x27/0x50
[  483.577594]  fbpf_prog_1906cf6roa66546b5e_handlem__kprobe_multi_crash+0x33/0x4d
u[  483.577596]  skprobe_multi_linek_handler+0x15d/r re0x260
[  483.577599]  t? kprobe_multi_lurink_handler+0x99n/0x260
[  483.577602]  e? __pfx_vfs_readd +0x10/0x10
0[  483.577604]   in? ksys_read+0x7c/0x100
 [  483.577605]  dm? vfs_read+0x4/0esg, x360
t[  483.577607]  fprobe_ftrace_entry+0x3b8/0x480
[  483.577609]  h? ksys_read+0x7ce /0x100
e[  483.577610]  x? fprobe_ftrace_pentry+0x93/0x480l
o[  483.577612]  it? lock_release+0x42/0x330
 [  483.577615]  ? vfs_read+0x9/0wx360
o[  483.577616]  r? __x64_sys_rt_sigaction+0xde/0xke120
[  483.577619]  ? vfs_read+0x9/0x360
[  483.577620]  d? ksys_read+0x7c./0x100
[  483.577622]  
? do_syscall_64+0x143/0xf80
[  483.577624]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  483.577625]  ? trace_irq_disable+0x1d/0xc0
[  483.577627]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  483.577631]  </TASK>

I am sending in a patch that fixes this.

Signed-off-by: Varun R Mallya <varunrmallya@xxxxxxxxx>