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

Varun R Mallya
2026-04-01T13:44:28Z

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.