All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Joe Perches <joe@perches.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-kernel@vger.kernel.org, kosaki.motohiro@jp.fujitsu.com,
	keescook@chromium.org, fweisbec@gmail.com,
	dan.carpenter@oracle.com, devel@driverdev.osuosl.org,
	gregkh@linuxfoundation.org, tushar.behera@linaro.org,
	lidza.louina@gmail.com, davem@davemloft.net,
	kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org,
	kaber@trash.net, courmisch@gmail.com, vyasevich@gmail.com,
	nhorman@tuxdriver.com, netdev@vger.kernel.org,
	linux-sctp@vger.kernel.org
Subject: Re: [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses
Date: Thu, 12 Sep 2013 00:19:11 +0000	[thread overview]
Message-ID: <20130912001911.GO13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1378944257.4714.45.camel@joe-AO722>

On Wed, Sep 11, 2013 at 05:04:17PM -0700, Joe Perches wrote:
> On Thu, 2013-09-12 at 08:40 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > -	seq_printf(m, "%s%d%n", con->name, con->index, &len);
> > > +	len = seq_printf(m, "%s%d", con->name, con->index);
> > 
> > Isn't len always 0 or -1 ?
> 
> Right.  Well you're no fun...
> 
> These uses would seem broken anyway because the
> seq_printf isn't itself tested for correctness.
> 
> Hmm.
> 
> Also, there's a large amount of code that appears
> to do calculations with pos or len like:
> 
> 	pos += seq_printf(handle, fmt. ...)

... and most of that code proceeds to ignore pos completely.
Note that ->show() is *NOT* supposed to return the number of
characters it has/would like to have produced.  Just return
0 and be done with that; overflows are dealt with just fine.
The large amount, BTW, is below 100 lines, AFAICS, in rather
few files.

> There are very few that seem to use it correctly
> like netfilter.

> Suggestions?

Just bury the cargo-culting crap.  All those += seq_printf() should
be simply calling it.  The *only* reason to look at the return
value is "if we'd already overflown the buffer, I'd rather skipped
the costly generation of the rest of the record".  In that case
seq_printf() returning -1 means "skip it, nothing else will fit and
caller will be repeating with bigger buffer anyway".

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Joe Perches <joe@perches.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-kernel@vger.kernel.org, kosaki.motohiro@jp.fujitsu.com,
	keescook@chromium.org, fweisbec@gmail.com,
	dan.carpenter@oracle.com, devel@driverdev.osuosl.org,
	gregkh@linuxfoundation.org, tushar.behera@linaro.org,
	lidza.louina@gmail.com, davem@davemloft.net,
	kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org,
	kaber@trash.net, courmisch@gmail.com, vyasevich@gmail.com,
	nhorman@tuxdriver.com, netdev@vger.kernel.org,
	linux-sctp@vger.kernel.org
Subject: Re: [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses
Date: Thu, 12 Sep 2013 01:19:11 +0100	[thread overview]
Message-ID: <20130912001911.GO13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1378944257.4714.45.camel@joe-AO722>

On Wed, Sep 11, 2013 at 05:04:17PM -0700, Joe Perches wrote:
> On Thu, 2013-09-12 at 08:40 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > -	seq_printf(m, "%s%d%n", con->name, con->index, &len);
> > > +	len = seq_printf(m, "%s%d", con->name, con->index);
> > 
> > Isn't len always 0 or -1 ?
> 
> Right.  Well you're no fun...
> 
> These uses would seem broken anyway because the
> seq_printf isn't itself tested for correctness.
> 
> Hmm.
> 
> Also, there's a large amount of code that appears
> to do calculations with pos or len like:
> 
> 	pos += seq_printf(handle, fmt. ...)

... and most of that code proceeds to ignore pos completely.
Note that ->show() is *NOT* supposed to return the number of
characters it has/would like to have produced.  Just return
0 and be done with that; overflows are dealt with just fine.
The large amount, BTW, is below 100 lines, AFAICS, in rather
few files.

> There are very few that seem to use it correctly
> like netfilter.

> Suggestions?

Just bury the cargo-culting crap.  All those += seq_printf() should
be simply calling it.  The *only* reason to look at the return
value is "if we'd already overflown the buffer, I'd rather skipped
the costly generation of the rest of the record".  In that case
seq_printf() returning -1 means "skip it, nothing else will fit and
caller will be repeating with bigger buffer anyway".

  reply	other threads:[~2013-09-12  0:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-11  4:41 [PATCH] staging: dgnc: fix potential format string flaw Kees Cook
2013-09-11  5:00 ` Joe Perches
2013-09-11  5:19   ` Kees Cook
2013-09-11  9:31     ` Dan Carpenter
2013-09-11 18:19       ` Kees Cook
2013-09-11 19:09         ` Joe Perches
2013-09-11 19:25           ` Kees Cook
2013-09-11 19:45             ` Joe Perches
2013-09-11 19:47               ` Kees Cook
2013-09-11 23:22                 ` [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses Joe Perches
2013-09-11 23:22                   ` Joe Perches
2013-09-11 23:29                   ` Kees Cook
2013-09-11 23:29                     ` Kees Cook
2013-09-11 23:29                     ` Kees Cook
2013-09-11 23:43                     ` Joe Perches
2013-09-11 23:43                       ` Joe Perches
2013-09-11 23:40                   ` Tetsuo Handa
2013-09-11 23:40                     ` Tetsuo Handa
2013-09-12  0:04                     ` Joe Perches
2013-09-12  0:04                       ` Joe Perches
2013-09-12  0:19                       ` Al Viro [this message]
2013-09-12  0:19                         ` Al Viro
2013-09-12  0:41                         ` Joe Perches
2013-09-12  0:41                           ` Joe Perches
2013-09-12  8:06                         ` David Laight
2013-09-12  8:06                           ` David Laight
2013-09-12 15:59                           ` Joe Perches
2013-09-12 15:59                             ` Joe Perches
2013-09-11 19:28           ` [PATCH] staging: dgnc: fix potential format string flaw Dan Carpenter
2013-09-11 19:22         ` Dan Carpenter
2013-09-11 19:26           ` Kees Cook

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=20130912001911.GO13318@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=courmisch@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jmorris@namei.org \
    --cc=joe@perches.com \
    --cc=kaber@trash.net \
    --cc=keescook@chromium.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=lidza.louina@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=tushar.behera@linaro.org \
    --cc=vyasevich@gmail.com \
    --cc=yoshfuji@linux-ipv6.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.