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

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.

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
+		 * 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.
+			 */
+			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';
-- 
2.1.3


  reply	other threads:[~2015-09-25 17:42 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 ` Rasmus Villemoes [this message]
2015-09-28  8:08   ` [PATCH 1/4] lib/vsprintf.c: handle invalid format specifiers more robustly Andy Shevchenko
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=1443202865-25533-2-git-send-email-linux@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®