linux-kernel - Re: [PATCH v16 09/10] unwind deferred: Use SRCU unwind_deferred_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250731211146.508d8387@batman.local.home>
Date: Thu, 31 Jul 2025 21:11:46 -0400
From: Steven Rostedt <rostedt@...nel.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 bpf@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>, Mathieu
 Desnoyers <mathieu.desnoyers@...icios.com>, Josh Poimboeuf
 <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar
 <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>, Arnaldo Carvalho de Melo
 <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Thomas Gleixner
 <tglx@...utronix.de>, Andrii Nakryiko <andrii@...nel.org>, Indu Bhagat
 <indu.bhagat@...cle.com>, "Jose E. Marchesi" <jemarch@....org>, Beau
 Belgrave <beaub@...ux.microsoft.com>, Jens Remus <jremus@...ux.ibm.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton
 <akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>, Florian Weimer
 <fweimer@...hat.com>, Sam James <sam@...too.org>
Subject: Re: [PATCH v16 09/10] unwind deferred: Use SRCU
 unwind_deferred_task_work()

On Thu, 31 Jul 2025 17:29:44 -0700
"Paul E. McKenney" <paulmck@...nel.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.965835871@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) {