Re: [PATCH] panic: fix va_list reuse in panic_try_force_cpu()

[Petr Mladek <pmladek@suse.com>]

On Sun 2026-07-05 12:10:14, Andrew Morton wrote:
> On Sun,  5 Jul 2026 16:41:23 +0000 Bradley Morgan <include@grrlz.net> wrote:
> 
> > vsnprintf() consumes the caller's va_list. When the redirect fails,
> > vpanic() reuses it for the panic message, which is undefined
> > behavior. Use va_copy().
> 
> Thanks.
> 
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -412,7 +412,12 @@ static bool panic_try_force_cpu(const char *fmt, va_list args)
> >  	 * fall back to static message for early boot panics or allocation failure.
> >  	 */
> >  	if (panic_force_buf) {
> > -		vsnprintf(panic_force_buf, PANIC_MSG_BUFSZ, fmt, args);
> > +		va_list ap;
> > +
> > +		/* Do not consume args, the caller reuses it if we fail */
> 
> Nice comment!
> 
> > +		va_copy(ap, args);
> > +		vsnprintf(panic_force_buf, PANIC_MSG_BUFSZ, fmt, ap);
> > +		va_end(ap);
> >  		msg = panic_force_buf;
> >  	} else {
> >  		msg = "Redirected panic (buffer unavailable)";
> 
> AI review found a possible pre-existing thing in there (as usual,
> sigh).  Seems pretty improbable:
> 
> 	https://sashiko.dev/#/patchset/20260705164123.18746-1-include@grrlz.net

Sashiko's comment is:

<paste>
This is a pre-existing issue, but looking at panic_try_force_cpu() in
kernel/panic.c, could concurrent panics bypass the panic_force_cpu
redirection?

If multiple CPUs enter panic() concurrently:

CPU A successfully sets panic_redirect_cpu:
    if (!atomic_try_cmpxchg(&panic_redirect_cpu, &old_cpu, this_cpu))
and eventually returns true to stop itself.

CPU B fails the cmpxchg on panic_redirect_cpu and returns false. Because
the target CPU (CPU C) hasn't yet started executing panic and hasn't set
panic_cpu, CPU B falls through to panic_try_start(). CPU B successfully
sets panic_cpu and handles the panic itself.

When CPU C eventually receives the IPI, it stops itself because panic_cpu
is already claimed.

Could this result in the crash kernel executing on a CPU other than the
one specified by panic_force_cpu?
</paste>

It has a point. panic_try_force_cpu() should return true when it can't
set panic_redirect_cpu. The panic() will be finished either by
the requested CPU or by the CPU which was able to set
panic_redirect_cpu.

I could send a patch. Or Bradley, would you like to send it?

Best Regards,
Petr