All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] lib/vsprintf: Fix to check field_width and precision
Date: Mon, 23 Mar 2026 13:59:05 +0000	[thread overview]
Message-ID: <20260323135905.5272127b@pumpkin> (raw)
In-Reply-To: <acE_w6grljfY_NDE@ashevche-desk.local>

On Mon, 23 Mar 2026 15:27:31 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Sat, Mar 21, 2026 at 11:41:12PM +0900, Masami Hiramatsu (Google) wrote:
> 
> > Check the field_width and presition correctly. Previously it depends
> > on the bitfield conversion from int to check out-of-range error.
> > However, commit 938df695e98d ("vsprintf: associate the format state
> > with the format pointer") changed those fields to int.
> > We need to check the out-of-range correctly without bitfield
> > conversion.  
> 
> ...
> 
> >  static void
> >  set_field_width(struct printf_spec *spec, int width)
> >  {
> > -	spec->field_width = width;
> > -	if (WARN_ONCE(spec->field_width != width, "field width %d too large", width)) {
> > -		spec->field_width = clamp(width, -FIELD_WIDTH_MAX, FIELD_WIDTH_MAX);
> > +	if (WARN_ONCE(width > FIELD_WIDTH_MAX || width < -FIELD_WIDTH_MAX,
> > +		      "field width %d too large", width)) {
> > +		width = clamp(width, -FIELD_WIDTH_MAX, FIELD_WIDTH_MAX);
> >  	}
> > +	spec->field_width = width;
> >  }
> >  
> >  static void
> >  set_precision(struct printf_spec *spec, int prec)
> >  {
> > -	spec->precision = prec;
> > -	if (WARN_ONCE(spec->precision != prec, "precision %d too large", prec)) {
> > -		spec->precision = clamp(prec, 0, PRECISION_MAX);
> > +	if (WARN_ONCE(prec > PRECISION_MAX || prec < 0,
> > +		      "precision %d too large", prec)) {
> > +		prec = clamp(prec, 0, PRECISION_MAX);
> >  	}
> > +	spec->precision = prec;
> >  }  
> 
> Looking at this, perhaps
> 
> #define clamp_WARN_*(...)
> 	...

When I looked at this I did wonder whether the compiler would manage to
only do the comparisons once.
Even if it doesn't the separate WARN is more readable.

Or maybe:
	spec->field_width = clamp(width, -FIELD_WIDTH_MAX, FIELD_WIDTH_MAX);
	WARN_ON(spec->field_width != width, "field width %d too large", width);

I'd be more worried about the bloat and system panic for all the systems
with panic_on_warn set (the default for many distos).
(And, like panic_on_oops, it doesn't give time for the error to get into
the system logs.)

I've also just fixed nolibc's handling of %*.*s (which is in 'next' since
I only wrote it recently), the above is actually broken.
Negative 'precision' (all values) are fine, they just request the default.

So the patch needs a big fat NACK...

	David


> 
> Potential users besides these two:
> 
> arch/powerpc/platforms/pseries/papr-sysparm.c-39-
> drivers/gpu/drm/drm_color_mgmt.c-142-
> drivers/gpu/drm/i915/display/intel_backlight.c-48-
> drivers/media/i2c/vgxy61.c-952-
> 


  reply	other threads:[~2026-03-23 13:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-21 14:41 [PATCH v3 0/2] lib/vsprintf: Fixes size check Masami Hiramatsu (Google)
2026-03-21 14:41 ` [PATCH v3 1/2] lib/vsprintf: Fix to check field_width and precision Masami Hiramatsu (Google)
2026-03-23 13:27   ` Andy Shevchenko
2026-03-23 13:59     ` David Laight [this message]
2026-03-24 16:45       ` Petr Mladek
2026-03-24 17:24         ` David Laight
2026-03-25  0:33           ` Masami Hiramatsu
2026-03-25  1:17             ` Masami Hiramatsu
2026-03-25  9:14               ` David Laight
2026-03-25  0:26     ` Masami Hiramatsu
2026-03-21 14:41 ` [PATCH v3 2/2] lib/vsprintf: Limit the returning size to INT_MAX Masami Hiramatsu (Google)
2026-03-24 16:50   ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260323135905.5272127b@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mhiramat@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.