summaryrefslogtreecommitdiffstats
path: root/drivers/bcma/README
diff options
context:
space:
mode:
authorRasmus Villemoes <linux@rasmusvillemoes.dk>2015-04-15 16:17:23 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2015-04-15 16:35:23 -0700
commit9c98f2359600386efd1c6adfabc5a04118a79798 (patch)
tree243d12ed1d4d8a1bfbf50331d33bdb3dd89a6d56 /drivers/bcma/README
parent900cca2944254edd2d54dc181629314d3177a4af (diff)
downloadlinux-stable-9c98f2359600386efd1c6adfabc5a04118a79798.tar.gz
linux-stable-9c98f2359600386efd1c6adfabc5a04118a79798.tar.bz2
linux-stable-9c98f2359600386efd1c6adfabc5a04118a79798.zip
lib/vsprintf.c: fix potential NULL deref in hex_string
The helper hex_string() is broken in two ways. First, it doesn't increment buf regardless of whether there is room to print, so callers such as kasprintf() that try to probe the correct storage to allocate will get a too small return value. But even worse, kasprintf() (and likely anyone else trying to find the size of the result) pass NULL for buf and 0 for size, so we also have end == NULL. But this means that the end-1 in hex_string() is (char*)-1, so buf < end-1 is true and we get a NULL pointer deref. I double-checked this with a trivial kernel module that just did a kasprintf(GFP_KERNEL, "%14ph", "CrashBoomBang"). Nobody seems to be using %ph with kasprintf, but we might as well fix it before it hits someone. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/bcma/README')
0 files changed, 0 insertions, 0 deletions