Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-19 Thread Tetsuo Handa
If the code to test is built into vmlinux, we could use run-time checking like -- --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -1601,6 +1601,11 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args) if (WARN_ON_ONCE((int) size < 0)) return 0; +

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-18 Thread Tetsuo Handa
Kees Cook wrote: > > -- output start -- > > const : literal > > not const : const char * > > not const : const char [] > > const : const char * const > > What version of gcc did you use? I don't get the last as const, for > some reason. And as Dan mentions, shouldn't const char[] b

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-18 Thread George Spelvin
> +#define printk(fmt, ...) do { \ > + compiletime_assert(__builtin_constant_p(fmt), \ > +"Non-constant format string"); \ > + printk(fmt, ##__VA_ARGS__); \ > +} while (0) May I recommend __builtin_constant_

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-18 Thread Kees Cook
On Wed, Sep 18, 2013 at 6:14 AM, Tetsuo Handa wrote: > Kees Cook wrote: >> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...) >> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal >> > and __vsnprintf(0, s, n, fmt, ...) otherwise. Now, >> > int __sprin

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-18 Thread Kees Cook
On Wed, Sep 18, 2013 at 6:14 AM, Tetsuo Handa wrote: > Kees Cook wrote: >> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...) >> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal >> > and __vsnprintf(0, s, n, fmt, ...) otherwise. Now, >> > int __sprin

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-18 Thread Dan Carpenter
On Wed, Sep 18, 2013 at 05:11:04PM +0300, Dan Carpenter wrote: > asmlinkage __printf(1, 2) __cold > int printk(const char *fmt, ...); > +#define printk(fmt, ...) do { \ > + compiletime_assert(__builtin_constant_p(fmt), \ > +"Non-con

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-18 Thread Dan Carpenter
Sure. There are a lot of non-const strings though. diff --git a/include/linux/printk.h b/include/linux/printk.h index e6131a78..317587b 100644 --- a/include/linux/printk.h +++ b/include/linux/printk.h @@ -122,6 +122,11 @@ asmlinkage int printk_emit(int facility, int level, asmlinkage __printf(

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-18 Thread Tetsuo Handa
Kees Cook wrote: > > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...) > > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal > > and __vsnprintf(0, s, n, fmt, ...) otherwise. Now, > > int __sprintf(int safe, char *buf, const char *fmt, ...) > > { > >

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-16 Thread Kees Cook
On Mon, Sep 16, 2013 at 8:55 AM, Al Viro wrote: > On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote: >> Whether seq_printf should return void or error, %n still needs to be removed. >> As such, instead of changing the seq_file structure and adding instructions >> to all callers of seq_prin

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-16 Thread George Spelvin
> This is completely pointless. *ANY* untrusted format string kernel-side > is pretty much it. Blocking %n is not "defense in depth", it's security > theater. Again, if attacker can feed an arbitrary format string to > vsnprintf(), it's over - you've lost. It's not just about information > leak

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-16 Thread Al Viro
On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote: > Whether seq_printf should return void or error, %n still needs to be removed. > As such, instead of changing the seq_file structure and adding instructions > to all callers of seq_printf, just examine seq->count for the callers that > car

Re: [PATCH 0/2] vsprintf: ignore %n again

2013-09-16 Thread Lars-Peter Clausen
On 09/16/2013 05:55 PM, Al Viro wrote: > On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote: >> Whether seq_printf should return void or error, %n still needs to be removed. >> As such, instead of changing the seq_file structure and adding instructions >> to all callers of seq_printf, just e

[PATCH 0/2] vsprintf: ignore %n again

2013-09-16 Thread Kees Cook
Whether seq_printf should return void or error, %n still needs to be removed. As such, instead of changing the seq_file structure and adding instructions to all callers of seq_printf, just examine seq->count for the callers that care about how many characters were put into the buffer, as suggested