linux-kernel - Re: [PATCH 2/2] proc: use set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <317b6413-0a46-8f5c-ad24-c5e183bc9a7a@prevas.dk>
Date:   Wed, 21 Feb 2018 09:57:49 +0100
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Alexey Dobriyan <adobriyan@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] proc: use set_puts() at /proc/*/wchan

On 2018-02-21 01:02, Andrew Morton wrote:
> On Sat, 17 Feb 2018 16:06:42 +0200 Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> 
>> On Sat, Feb 17, 2018 at 9:20 AM, Alexey Dobriyan <adobriyan@...il.com> wrote:
>>> Signed-off-by: Alexey Dobriyan <adobriyan@...il.com>
>>
>>
>>> -               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
done.

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.

Rasmus