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.

Acked-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk>
---
 lib/vsprintf.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index ec337f64f52d..3568e3906777 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -782,11 +782,19 @@ char *hex_string(char *buf, char *end, u8 *addr, struct 
printf_spec spec,
        if (spec.field_width > 0)
                len = min_t(int, spec.field_width, 64);
 
-       for (i = 0; i < len && buf < end - 1; i++) {
-               buf = hex_byte_pack(buf, addr[i]);
+       for (i = 0; i < len; ++i) {
+               if (buf < end)
+                       *buf = hex_asc_hi(addr[i]);
+               ++buf;
+               if (buf < end)
+                       *buf = hex_asc_lo(addr[i]);
+               ++buf;
 
-               if (buf < end && separator && i != len - 1)
-                       *buf++ = separator;
+               if (separator && i != len - 1) {
+                       if (buf < end)
+                               *buf = separator;
+                       ++buf;
+               }
        }
 
        return buf;
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to