All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 1/4] lib/vsprintf.c: handle invalid format specifiers more robustly
Date: Mon, 28 Sep 2015 11:08:11 +0300	[thread overview]
Message-ID: <1443427691.8361.226.camel@linux.intel.com> (raw)
In-Reply-To: <1443202865-25533-2-git-send-email-linux@rasmusvillemoes.dk>

On Fri, 2015-09-25 at 19:41 +0200, Rasmus Villemoes wrote:
> If we meet any invalid or unsupported format specifier, 'handling' it
> by just printing it as a literal string is not safe: Presumably the
> format string and the arguments passed gcc's type checking, but that
> means something like sprintf(buf, "%n %pd", &intvar, dentry) would 
> end
> up interpreting &intvar as a struct dentry*.
> 
> When the offending specifier was %n it used to be at the end of the
> format string, but we can't rely on that always being the case. Also,
> gcc doesn't complain about some more or less exotic qualifiers (or
> 'length modifiers' in posix-speak) such as 'j' or 'q', but being
> unrecognized by the kernel's printf implementation, they'd be
> interpreted as unknown specifiers, and the rest of arguments would be
> interpreted wrongly.
> 
> So let's complain about anything we don't understand, not just %n, 
> and
> stop pretending that we'd be able to make sense of the rest of the
> format/arguments. If the offending specifier is in a printk() call we
> unfortunately only get a "BUG: recent printk recursion!", but at 
> least
> direct users of the sprintf family will be caught.

I like the fix (I noticed the same issue after commented out Martin's
patch).

Few minor comments below.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>  lib/vsprintf.c | 31 +++++++++++++++++++++----------
>  1 file changed, 21 insertions(+), 10 deletions(-)
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 95cd63b43b99..f2590a80937f 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1769,14 +1769,14 @@ qualifier:
>  
>  	case 'n':
>  		/*
> -		 * Since %n poses a greater security risk than 
> utility, treat
> -		 * it as an invalid format specifier. Warn about its 
> use so
> -		 * that new instances don't get added.
> +		 * Since %n poses a greater security risk than

Any reason to wrap first string?

> +		 * utility, treat it as any other invalid or
> +		 * unsupported format specifier.
>  		 */
> -		WARN_ONCE(1, "Please remove ignored %%n in '%s'\n", 
> fmt);
>  		/* Fall-through */
>  
>  	default:
> +		WARN_ONCE(1, "Please remove unsupported %%%c in 
> format string\n", *fmt);
>  		spec->type = FORMAT_TYPE_INVALID;
>  		return fmt - start;
>  	}
> @@ -1944,10 +1944,15 @@ int vsnprintf(char *buf, size_t size, const 
> char *fmt, va_list args)
>  			break;
>  
>  		case FORMAT_TYPE_INVALID:
> -			if (str < end)
> -				*str = '%';
> -			++str;
> -			break;
> +			/*
> +			 * Presumably the arguments passed gcc's 
> type
> +			 * checking, but there is no safe or sane 
> way
> +			 * for us to continue parsing the format and
> +			 * fetching from the va_list; the remaining
> +			 * specifiers and arguments would be out of
> +			 * sync.

Could we use wider strings in the commentary here?

> +			 */
> +			goto out;
>  
>  		default:
>  			switch (spec.type) {
> @@ -1992,6 +1997,7 @@ int vsnprintf(char *buf, size_t size, const 
> char *fmt, va_list args)
>  		}
>  	}
>  
> +out:
>  	if (size > 0) {
>  		if (str < end)
>  			*str = '\0';
> @@ -2189,9 +2195,10 @@ do {						> 	> 	> 	> \
> 
>  
>  		switch (spec.type) {
>  		case FORMAT_TYPE_NONE:
> -		case FORMAT_TYPE_INVALID:
>  		case FORMAT_TYPE_PERCENT_CHAR:
>  			break;
> +		case FORMAT_TYPE_INVALID:
> +			goto out;
>  
>  		case FORMAT_TYPE_WIDTH:
>  		case FORMAT_TYPE_PRECISION:
> @@ -2253,6 +2260,7 @@ do {						> 	> 	> 	> \
> 
>  		}
>  	}
>  
> +out:
>  	return (u32 *)(PTR_ALIGN(str, sizeof(u32))) - bin_buf;
>  #undef save_arg
>  }
> @@ -2375,12 +2383,14 @@ int bstr_printf(char *buf, size_t size, const 
> char *fmt, const u32 *bin_buf)
>  			break;
>  
>  		case FORMAT_TYPE_PERCENT_CHAR:
> -		case FORMAT_TYPE_INVALID:
>  			if (str < end)
>  				*str = '%';
>  			++str;
>  			break;
>  
> +		case FORMAT_TYPE_INVALID:
> +			goto out;
> +
>  		default: {
>  			unsigned long long num;
>  
> @@ -2423,6 +2433,7 @@ int bstr_printf(char *buf, size_t size, const 
> char *fmt, const u32 *bin_buf)
>  		} /* switch(spec.type) */
>  	} /* while(*fmt) */
>  
> +out:
>  	if (size > 0) {
>  		if (str < end)
>  			*str = '\0';

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2015-09-28  8:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-25 17:41 [PATCH 0/4] printf stuff Rasmus Villemoes
2015-09-25 17:41 ` [PATCH 1/4] lib/vsprintf.c: handle invalid format specifiers more robustly Rasmus Villemoes
2015-09-28  8:08   ` Andy Shevchenko [this message]
2015-09-28 20:12     ` Rasmus Villemoes
2015-09-28 22:30   ` Kees Cook
2015-09-25 17:41 ` [PATCH 2/4] lib/vsprintf.c: also improve sanity check in bstr_printf() Rasmus Villemoes
2015-09-28 22:31   ` Kees Cook
2015-09-25 17:41 ` [PATCH 3/4] lib/vsprintf.c: Remove SPECIAL handling in pointer() Rasmus Villemoes
2015-09-28  8:55   ` Andy Shevchenko
2015-09-25 17:41 ` [PATCH 4/4] test_printf: test printf family at runtime Rasmus Villemoes
2015-09-28  9:12   ` Andy Shevchenko
2015-09-28 20:55     ` Rasmus Villemoes
2015-09-30  6:38       ` Andy Shevchenko
2015-09-30  8:56         ` Rasmus Villemoes
2015-09-28 22:38   ` Kees Cook
2015-09-29  7:10     ` Rasmus Villemoes
2015-09-29 17:32       ` Kees Cook
2015-09-30  9:05         ` Rasmus Villemoes
2015-09-30 15:30 ` [PATCH v2 0/4] printf stuff Rasmus Villemoes
2015-09-30 15:30   ` [PATCH v2 1/4] lib/vsprintf.c: handle invalid format specifiers more robustly Rasmus Villemoes
2015-09-30 15:30   ` [PATCH v2 2/4] lib/vsprintf.c: also improve sanity check in bstr_printf() Rasmus Villemoes
2015-09-30 15:30   ` [PATCH v2 3/4] lib/vsprintf.c: Remove SPECIAL handling in pointer() Rasmus Villemoes
2015-09-30 15:40     ` Andy Shevchenko
2015-09-30 15:30   ` [PATCH v2 4/4] test_printf: test printf family at runtime Rasmus Villemoes

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1443427691.8361.226.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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