linux-kernel - Re: drivers: random: Shift out-of-bounds in _mix_pool

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]

Date:	Sat, 25 Oct 2014 21:30:17 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Andreas Dilger <adilger@...ger.ca>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Theodore Ts'o" <tytso@....edu>,
	Daniel Borkmann <dborkman@...hat.com>,
	Andrey Ryabinin <a.ryabinin@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Michal Marek <mmarek@...e.cz>,
	"x86@...nel.org" <x86@...nel.org>, linux-kbuild@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Konstantin Khlebnikov <koct9i@...il.com>
Subject: Re: drivers: random: Shift out-of-bounds in _mix_pool_bytes

On Fri, 24 Oct 2014 20:50:46 -0400
Sasha Levin <sasha.levin@...cle.com> wrote:

> On 10/24/2014 06:22 PM, H. Peter Anvin wrote:
> >> By the principle of least surprise, I would expect "__u32 >> N", where
> >> > N >= 32 to return zero instead of random garbage.  For N < 32 it will
> >> > return progressively smaller numbers, until it has shifted away all of
> >> > the set bits, at which turn it will return 0.  For it suddenly to jump
> >> > up once N = 32 is used, is counter-intuitive.
> >> > 
> > That's why it is undefined.
> 
> Now I'm curious about things like "memcpy(ptr, NULL, 0)". According to the
> standard they're undefined, and since we're using gcc's implementation for
> memcpy() we are doing "undefined memcpy" in quite a few places in the kernel.
> 
> Is it an issue, or would you expect memcpy() to not deref the "from" ptr
> since length is 0?

No. Furthermore gcc 4.9 actually has optimiser magic around this. See the
"Porting to gcc 4.9" notes.

--------

 GCC might now optimize away the null pointer check in code like:


  int copy (int* dest, int* src, size_t nbytes) {
    memmove (dest, src, nbytes);
    if (src != NULL)
      return *src;
    return 0;
  }

The pointers passed to memmove (and similar functions in <string.h>) must
be non-null even when nbytes==0, so GCC can use that information to
remove the check after the memmove call. Calling copy(p, NULL, 0) can
therefore deference a null pointer and crash.

-------------

Which is unfortunate because an operating system has a lot of legitimate
reasons to copy data to address 0 (on many processors its the exception
vectors for example)

Alan
--
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/