Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755397Ab3ILHbP (ORCPT ); Thu, 12 Sep 2013 03:31:15 -0400 Received: from mail-ob0-f175.google.com ([209.85.214.175]:45619 "EHLO mail-ob0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751689Ab3ILHbN (ORCPT ); Thu, 12 Sep 2013 03:31:13 -0400 MIME-Version: 1.0 In-Reply-To: <5231836102000078000F29AD@nat28.tlf.novell.com> References: <20130911193040.GA16688@www.outflux.net> <1378929961.4714.21.camel@joe-AO722> <5231836102000078000F29AD@nat28.tlf.novell.com> Date: Thu, 12 Sep 2013 00:31:12 -0700 X-Google-Sender-Auth: rQ7igQJ8Wg3gxITfqQ6xgnVAzkc Message-ID: Subject: Re: [PATCH] vsprintf: drop comment claiming %n is ignored From: Kees Cook To: Jan Beulich Cc: Joe Perches , David Miller , Eldad Zack , George Spelvin , Randy Dunlap , Andrew Morton , Dan Carpenter , Jiri Kosina , LKML Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1841 Lines: 41 On Thu, Sep 12, 2013 at 12:03 AM, Jan Beulich wrote: >>>> On 11.09.13 at 22:18, Kees Cook wrote: >> On Wed, Sep 11, 2013 at 1:06 PM, Joe Perches 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. Since there are so few users of %n in the kernel, it seems that this goal is not totally outside the realm of possibility in the short-term. The inclusion of the WARN_ON() was suggested for the very reason of helping a potential user of %n to notice that it's not supported. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/