CVE-2026-93173: bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks
In the Linux kernel, the following vulnerability has been resolved:
bpf,lsm: Drop bpfprogfree from sleepablelsmhooks
bpfprogputrcu() is the callrcu() callback for non-sleepable programs. securitybpfprogfree() called from there fires bpfprogfree in softirq; if a sleepable LSM prog is attached to that hook, mightfault() BUGs:
BUG: sleeping function called from invalid context inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 5038 preemptcount: 101, expected: 0 Call Trace: <IRQ> bpfprogentersleepable+0x1cd/0x320 kernel/bpf/trampoline.c:1255 bpftrampoline6442549705+0x53/0xd7 securitybpfprogfree+0xde/0x130 security/security.c:5465 bpfprogputrcu+0xab/0xd0 kernel/bpf/syscall.c:2365 rcudobatch kernel/rcu/tree.c:2617 [inline] handlesoftirqs+0x236/0x800 kernel/softirq.c:622 </IRQ>
The callrcu/callrcutaskstrace split reflects the freed program's sleepability, not that of any attached observer.
securitybpfprogfree() also frees prog->aux->security, which has to stay after the grace period, so drop bpfprogfree from sleepablelsmhooks rather than move the call. Non-sleepable observers still run there.
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to the failure condition?
The issue affects Linux kernel environments where a sleepable BPF LSM program is attached to the bpf_prog_free hook. Non-sleepable observers can still run from that hook and are not the condition described as triggering the BUG.
What event triggers the BUG?
The failure can occur when security_bpf_prog_free() is invoked by __bpf_prog_put_rcu() from an RCU callback running in softirq context while a sleepable LSM program is attached to bpf_prog_free. The sleepable program may call might_fault() in that atomic context, causing a “sleeping function called from invalid context” BUG.
What is the mitigation if the kernel update cannot be applied immediately?
Avoid attaching sleepable BPF LSM programs to the bpf_prog_free hook. The described fix removes bpf_prog_free from the sleepable LSM hooks while retaining non-sleepable observers.
How can administrators identify whether they have encountered this issue?
Look for a kernel BUG reporting “sleeping function called from invalid context” with a stack trace involving __bpf_prog_enter_sleepable, security_bpf_prog_free, __bpf_prog_put_rcu, rcu_do_batch, and handle_softirqs.