All of
 help / color / mirror / Atom feed
From: Rasmus Villemoes <>
To: Andrew Morton <>,
	Andy Shevchenko <>
Cc: Alexey Dobriyan <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH 2/2] proc: use set_puts() at /proc/*/wchan
Date: Wed, 21 Feb 2018 09:57:49 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2018-02-21 01:02, Andrew Morton wrote:
> On Sat, 17 Feb 2018 16:06:42 +0200 Andy Shevchenko <> wrote:
>> On Sat, Feb 17, 2018 at 9:20 AM, Alexey Dobriyan <> wrote:
>>> Signed-off-by: Alexey Dobriyan <>
>>> -               seq_printf(m, "%s", symname);
>>> +               seq_puts(m, symname);
>> While this might have no security concerns, the pattern might be
>> brainlessly used by some janitors and there would have security
>> implications.
> And I'd like to see a changelog, please.  One which explains why
> `symname' cannot have a %s (etc) in it, and never will.

OK, since #youtoo: It doesn't _matter_ if symname is "%pHAHAHA %fooled
you <unicode for evil grin emoji>", seq_puts does not interpret it at
all. There are _never_ security implications with the above replacement.
Sure, seq_printf(m, symname) would be bad, but that's not what is being

AFAICT, this should always lead to slightly smaller code (one less
parameter passed) and in all likelyhood also slightly faster (no format
interpretation, no slow char-by-char handling by the string() function
etc.). So the only case where I'd think this should not necessarily be
done would be in a long sequence of seq_printf, where only one or two
could be replaced by seq_puts/seq_putc.


  reply	other threads:[~2018-02-21  8:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-17  7:20 [PATCH 2/2] proc: use set_puts() at /proc/*/wchan Alexey Dobriyan
2018-02-17 14:06 ` Andy Shevchenko
2018-02-17 15:35   ` Alexey Dobriyan
2018-02-21  0:02   ` Andrew Morton
2018-02-21  8:57     ` Rasmus Villemoes [this message]
2018-02-21 20:27       ` Andrew Morton

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:

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

  git send-email \ \ \ \ \ \ \

* 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.