Re: [PATCH] vsprintf: drop comment claiming %n is ignored

[Jan Beulich]

>>> On 12.09.13 at 09:31, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> On Thu, Sep 12, 2013 at 12:03 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 11.09.13 at 22:18, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>>> On Wed, Sep 11, 2013 at 1:06 PM, Joe Perches <joe@xxxxxxxxxxx> wrote:
>>>> On Wed, 2013-09-11 at 12:30 -0700, Kees Cook wrote:
>>>>> The %n format is not ignored, so remove the incorrect comment about it.
>>>>
>>>> I think it may be better to reimplement the ignoring.
>>>
>>> Yeah, just had a quick look, and scanf doesn't use this code at all.
>>> I'd much rather remove %n again instead.
>>
>> Why would you want to artificially make the function diverge
>> from the spec? People shouldn't be caught by surprises if at all
>> possible, and one can certainly not expect people to go look at
>> the comment before the function implementation to find out
>> what basic (standard) features _do not_ work (one can expect
>> so when trying to find out about _extensions_).
> 
> The spec, in this case, is considered harmful. Without %n, format
> string flaws are at worst "just" information leaks. Being able to
> downgrade potential arbitrary memory writing vulnerabilities into info
> leak vulnerabilities would be a very nice improvement. As another
> point of reference, even Android's libc replacement, bionic, doesn't
> implement %n for the very same reasons.

Pretty strange argumentation: You disallow people knowing what
they do using this just to keep people not knowing what they do
from making mistakes? That may make sense in script languages,
but not in C (not to speak of in the kernel). In the end this seems
like enforcing a Google policy on everyone. But sure - if Linus is
willing to merge this, my objection likely doesn't count much.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/