]> git.karo-electronics.de Git - karo-tx-linux.git/commit
lib/vsprintf.c: handle invalid format specifiers more robustly
authorRasmus Villemoes <linux@rasmusvillemoes.dk>
Wed, 21 Oct 2015 22:03:50 +0000 (09:03 +1100)
committerStephen Rothwell <sfr@canb.auug.org.au>
Wed, 21 Oct 2015 22:03:50 +0000 (09:03 +1100)
commit99fe02fd86ff80279a3b728813038659bacd8d21
treef8bf1282096e1aa8af4335185cb36cc259eb98f2
parent140212afe2b6d0dad77f05982946ea2b9139478a
lib/vsprintf.c: handle invalid format specifiers more robustly

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>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Martin Kletzander <mkletzan@redhat.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
lib/vsprintf.c