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

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

[Bradley Morgan]

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().

Signed-off-by: Bradley Morgan <include@grrlz.net>
---
 kernel/panic.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index f9ad0250da67..03f1eef07b17 100644
--- 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 */
+		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)";
-- 
2.53.0

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

[Andrew Morton]

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

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

[Petr Mladek]

On Sun 2026-07-05 16:41:23, Bradley Morgan 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().
> 
> Signed-off-by: Bradley Morgan <include@grrlz.net>

Great catch!

The patch looks good to me:

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr

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

[Petr Mladek]

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