From: Petr Mladek <pmladek@suse.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Richard Fitzgerald <rf@opensource.cirrus.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Shuah Khan <shuah@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
patches@opensource.cirrus.com
Subject: Re: [PATCH v4 2/4] lib: vsprintf: Fix handling of number field widths in vsscanf
Date: Mon, 8 Feb 2021 18:56:07 +0100 [thread overview]
Message-ID: <YCF7N0Fc9WC9flyd@alley> (raw)
In-Reply-To: <CAHp75VcARyR4YvnWoVk1gnR8v7u_YJPnV0x3Mbe7iLMrvpbSAQ@mail.gmail.com>
On Fri 2021-02-05 14:50:56, Andy Shevchenko wrote:
> On Fri, Feb 5, 2021 at 1:35 PM Richard Fitzgerald
> <rf@opensource.cirrus.com> wrote:
> > On 04/02/2021 16:35, Petr Mladek wrote:
> > > On Wed 2021-02-03 21:45:55, Andy Shevchenko wrote:
> > >> On Wed, Feb 03, 2021 at 04:50:07PM +0000, Richard Fitzgerald wrote:
> > >> This allows max_char to be an unsigned type.
> > >>
> > >> Moreover...
> > >>
> > >>> + return _parse_integer_limit(s, base, p, INT_MAX);
> > >>
> > >> You have inconsistency with INT_MAX vs, size_t above.
> > >
> > > Ah, this was on my request. INT_MAX is already used on many other
> > > locations in vsnprintf() for this purpose.
> >
> > I originally had UINT_MAX and changed on Petr's request to be
> > consistent with other code. (Sorry Andy - my mistake not including
> > you on the earlier review versions).
> >
> > But 0 < INT_MAX < UINT_MAX, so ok to pass to an unsigned. And as Petr
> > said on his original review, INT_MAX is "big enough".
>
> Some code has INT_MAX, some has UINT_MAX, while the parameter is size_t.
Yeah, if I remember correctly I wanted to have INT_MAX everywhere but
I did not want to nitpick about it in the later versions. It looked
like an arbitrary number anyway.
> I think all of these inconsistencies should have a comment either in
> the code, or in the commit message, or in the cover letter (depending
> on the importance).
> Or being fixed to be more consistent with existing code. Whichever you
> consider better.
OK, you made me to do some archaeology. The INT_MAX limit has
been added into vsnprintf() in 2.6.2 by the commit:
Author: Linus Torvalds <torvalds@home.osdl.org>
Date: Mon Feb 2 21:17:29 2004 -0800
Warn loudly if somebody passes a negative value as
the size to "vsnprintf()".
That's a pretty clear case of overflow.
It might catch problems. And the limit seems to have worked all the time.
IMHO, it would make sense to have INT_MAX limit also in
_parse_integer_limit() and WARN() when a larger value is passed.
By other words, it would mean to add this check and use INT_MAX
everywhere in this patch.
Best Regards,
Petr
next prev parent reply other threads:[~2021-02-08 17:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 16:50 [PATCH v4 1/4] lib: vsprintf: scanf: Negative number must have field width > 1 Richard Fitzgerald
2021-02-03 16:50 ` [PATCH v4 2/4] lib: vsprintf: Fix handling of number field widths in vsscanf Richard Fitzgerald
2021-02-03 19:45 ` Andy Shevchenko
2021-02-04 16:35 ` Petr Mladek
2021-02-05 11:28 ` Richard Fitzgerald
2021-02-05 12:50 ` Andy Shevchenko
2021-02-05 15:23 ` David Laight
2021-02-05 15:53 ` Andy Shevchenko
2021-02-08 17:56 ` Petr Mladek [this message]
2021-02-08 11:47 ` Richard Fitzgerald
2021-02-03 16:50 ` [PATCH v4 3/4] lib: test_scanf: Add tests for sscanf number conversion Richard Fitzgerald
2021-02-03 19:47 ` Andy Shevchenko
2021-02-03 16:50 ` [PATCH v4 4/4] selftests: lib: Add wrapper script for test_scanf Richard Fitzgerald
2021-02-03 19:48 ` Andy Shevchenko
2021-02-03 19:48 ` [PATCH v4 1/4] lib: vsprintf: scanf: Negative number must have field width > 1 Andy Shevchenko
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=YCF7N0Fc9WC9flyd@alley \
--to=pmladek@suse.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=patches@opensource.cirrus.com \
--cc=rf@opensource.cirrus.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=shuah@kernel.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.