linux-kernel - Re: [PATCH 1/2] lib/vsprintf.c: Fix potential NULL deref in hex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y4omzz0u.fsf@rasmusvillemoes.dk>
Date:	Wed, 28 Jan 2015 16:49:05 +0100
From:	Rasmus Villemoes <linux@...musvillemoes.dk>
To:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Randy Dunlap <rdunlap@...radead.org>,
	Fabian Frederick <fabf@...net.be>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Ryan Mallon <rmallon@...il.com>,
	Masanari Iida <standby24x7@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] lib/vsprintf.c: Fix potential NULL deref in hex_string

On Wed, Jan 28 2015, Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> On Wed, 2015-01-28 at 14:25 +0100, Rasmus Villemoes wrote:
>> 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").
>
> Good catch, though I don't like the implementation of fix.
>
> What about the following?
>
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 8690798..47b36ddd 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -783,11 +783,20 @@ 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;

I had exactly that at one point. I think the only reason I ended up
doing it the other way was that I wanted to introduce the write_bytes
helper, and then use that to do some simplifications and optimizations
for other %p helpers. Many of those write their output to a temporary
buffer, knowing exactly how much there is, then delegate to string(),
which then recomputes the string length before printing. But all that
can be done another time, so I'm fine with this also.

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