On Thu, 31 Jul 2025 17:29:44 -0700 "Paul E. McKenney" <paul...@kernel.org> wrote:
> > @@ -281,10 +291,15 @@ void unwind_deferred_cancel(struct unwind_work *work) > > return; > > > > guard(mutex)(&callback_mutex); > > - list_del(&work->list); > > What happens if unwind_deferred_task_work() finds this item right here... Should be fine. > > > + list_del_rcu(&work->list); > > ...and then unwind_deferred_request() does its WARN_ON_ONCE() check > against -1 right here? If unwind_deferred_request() is called after unwind_deferred_cancel() then that's a bug. As both functions are called by the tracer. The cancel() function is for the tracer to tell this infrastructure that it's done with the deferred tracing. If it calls a request() function after (or during) the call to cancel(), then it's a bug in the tracer. The tracer is responsible for making sure it will not do any more requests before calling the cancel() function. But what the tracer can't do is to know if there's a pending request still happening and this has to handle that. > > Can't that cause UAF? > > This is quite possibly a stupid question because I am not seeing where to > apply this patch, so I don't know what other mechanisms might be in place. Yeah, you were only Cc'd on this patch because it was the only one that uses RCU. You can see the entire series here: https://lore.kernel.org/all/20250729182304.965835...@kernel.org/ Or in patchwork: https://patchwork.kernel.org/project/linux-trace-kernel/list/?series=986813 -- Steve > > > + /* Do not allow any more requests and prevent callbacks */ > > + work->bit = -1; > > > > __clear_bit(bit, &unwind_mask); > > > > + synchronize_srcu(&unwind_srcu); > > + > > guard(rcu)(); > > /* Clear this bit from all threads */ > > for_each_process_thread(g, t) {
