On Fri, Aug 07, 2026 at 02:00:11AM +0000, Hui Zhu wrote: > > > > On Wed, Aug 05, 2026 at 12:04:05PM +0800, Hui Zhu wrote: > > > > > > > > From: Hui Zhu <[email protected]> > > > > > > This series fixes several use-after-free issues in the BPF trampoline > > > multi-attach/detach error paths, where ftrace direct-call updates can > > > fail and leave ftrace pointing at freed memory. > > > > > hi, > > I need to stare at it bit more, but tbh I'm not sure the benefit of > > preventing hypothetical crash is worth the extra complexity on the > > detach side > > > > IIUC we can't reproduce this error without instrumenting the code, right? > > > > jirka > > Hi Jiri, > > You're right. I went through the failure paths and the realistic > triggers basically don't exist for a normal user: > > The allocations are all GFP_KERNEL (reclaim + OOM handle them), > and bpf_jit_charge_modmem() lets CAP_BPF callers exceed the JIT > limit, so ENOMEM doesn't get there. > -E2BIG is attach-time, before cur_image is set, so no UAF. > SHARE_IPMODIFY -EAGAIN needs livepatch on the same function and > is retried in bpf_trampoline_update(); the multi path where it > could escape needs a second failure on the undo del, which doesn't > do ipmodify negotiation, so it doesn't reach the UAF either. > The rest is bugs or not user-driven. > > So this is fault-injection territory, and I won't claim it's > a customer bug. > > I'd like to drop patches 2 and 3 and the prog-side machinery > (pinned_prog + rollback + the trampoline leak). > And keep only the one-line image-side fix in patch 1: only free > old_image when it differs from cur_image.
right, that one looks good > It's obviously correct: if cur_image == old_image, ftrace is still > calling into it, so freeing it is wrong. And it costs almost nothing. > > Would you prefer I proceed with just this single patch, > or drop the entire series instead? also we can change bpf_trampoline_multi_detach to return void and drop the WARN_ON_ONCE on that call thanks, jirka
