linux-stable.git/drivers/char/random.c, branch v4.6.7

random: strengthen input validation for RNDADDTOENTCNT

2016-08-16T07:33:17+00:00

commit 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec upstream.

Don't allow RNDADDTOENTCNT or RNDADDENTROPY to accept a negative
entropy value.  It doesn't make any sense to subtract from the entropy
counter, and it can trigger a warning:

random: negative entropy/overflow: pool input count -40000
------------[ cut here ]------------
WARNING: CPU: 3 PID: 6828 at drivers/char/random.c:670[<      none
 >] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
Modules linked in:
CPU: 3 PID: 6828 Comm: a.out Not tainted 4.7.0-rc4+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffffffff880b58e0 ffff88005dd9fcb0 ffffffff82cc838f ffffffff87158b40
 fffffbfff1016b1c 0000000000000000 0000000000000000 ffffffff87158b40
 ffffffff83283dae 0000000000000009 ffff88005dd9fcf8 ffffffff8136d27f
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x12e/0x18f lib/dump_stack.c:51
 [] __warn+0x19f/0x1e0 kernel/panic.c:516
 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:551
 [] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
 [<     inline     >] credit_entropy_bits_safe drivers/char/random.c:734
 [] random_ioctl+0x21d/0x250 drivers/char/random.c:1546
 [<     inline     >] vfs_ioctl fs/ioctl.c:43
 [] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
 [<     inline     >] SYSC_ioctl fs/ioctl.c:689
 [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
 [] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
---[ end trace 5d4902b2ba842f1f ]---

This was triggered using the test program:

// autogenerated by syzkaller (http://github.com/google/syzkaller)

int main() {
        int fd = open("/dev/random", O_RDWR);
        int val = -5000;
        ioctl(fd, RNDADDTOENTCNT, &val);
        return 0;
}

It's harmless in that (a) only root can trigger it, and (b) after
complaining the code never does let the entropy count go negative, but
it's better to simply not allow this userspace from passing in a
negative entropy value altogether.

Google-Bug-Id: #29575089
Reported-By: Dmitry Vyukov 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

drivers: char: random: add get_random_long()

2016-02-27T18:28:52+00:00

Commit d07e22597d1d ("mm: mmap: add new /proc tunable for mmap_base
ASLR") added the ability to choose from a range of values to use for
entropy count in generating the random offset to the mmap_base address.

The maximum value on this range was set to 32 bits for 64-bit x86
systems, but this value could be increased further, requiring more than
the 32 bits of randomness provided by get_random_int(), as is already
possible for arm64.  Add a new function: get_random_long() which more
naturally fits with the mmap usage of get_random_int() but operates
exactly the same as get_random_int().

Also, fix the shifting constant in mmap_rnd() to be an unsigned long so
that values greater than 31 bits generate an appropriate mask without
overflow.  This is especially important on x86, as its shift instruction
uses a 5-bit mask for the shift operand, which meant that any value for
mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base
randomization.

Finally, replace calls to get_random_int() with get_random_long() where
appropriate.

This patch (of 2):

Add get_random_long().

Signed-off-by: Daniel Cashman 
Acked-by: Kees Cook 
Cc: "Theodore Ts'o" 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: David S. Miller 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Al Viro 
Cc: Nick Kralevich 
Cc: Jeff Vander Stoep 
Cc: Mark Salyzyn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

random: Remove kernel blocking API

2015-06-10T11:14:04+00:00

This patch removes the kernel blocking API as it has been completely
replaced by the callback API.

Signed-off-by: Herbert Xu

random: Add callback API for random pool readiness

2015-06-10T11:13:56+00:00

The get_blocking_random_bytes API is broken because the wait can
be arbitrarily long (potentially forever) so there is no safe way
of calling it from within the kernel.

This patch replaces it with a callback API instead.  The callback
is invoked potentially from interrupt context so the user needs
to schedule their own work thread if necessary.

In addition to adding callbacks, they can also be removed as
otherwise this opens up a way for user-space to allocate kernel
memory with no bound (by opening algif_rng descriptors and then
closing them).

Signed-off-by: Herbert Xu

random: Blocking API for accessing nonblocking_pool

2015-05-27T09:51:53+00:00

The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.

CC: Andreas Steffen 
CC: Theodore Ts'o 
CC: Sandy Harris 
Signed-off-by: Stephan Mueller 
Signed-off-by: Herbert Xu

random: Wake up all getrandom(2) callers when pool is ready

2015-05-27T09:51:45+00:00

If more than one application invokes getrandom(2) before the pool
is ready, then all bar one will be stuck forever because we use
wake_up_interruptible which wakes up a single task.

This patch replaces it with wake_up_all.

Signed-off-by: Herbert Xu

random: Fix fast_mix() function

2015-02-09T20:28:42+00:00

There was a bad typo in commit 43759d4f429c ("random: use an improved
fast_mix() function") and I didn't notice because it "looked right", so
I saw what I expected to see when I reviewed it.

Only months later did I look and notice it's not the Threefish-inspired
mix function that I had designed and optimized.

Mea Culpa.  Each input bit still has a chance to affect each output bit,
and the fast pool is spilled *long* before it fills, so it's not a total
disaster, but it's definitely not the intended great improvement.

I'm still working on finding better rotation constants.  These are good
enough, but since it's unrolled twice, it's possible to get better
mixing for free by using eight different constants rather than repeating
the same four.

Signed-off-by: George Spelvin 
Cc: Theodore Ts'o 
Cc: stable@vger.kernel.org  # v3.16+
Signed-off-by: Linus Torvalds

Merge tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random

2014-10-24T19:33:32+00:00

Pull /dev/random updates from Ted Ts'o:
 "This adds a memzero_explicit() call which is guaranteed not to be
  optimized away by GCC.  This is important when we are wiping
  cryptographically sensitive material"

* tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
  crypto: memzero_explicit - make sure to clear out sensitive data
  random: add and use memzero_explicit() for clearing data

random: add and use memzero_explicit() for clearing data

2014-10-17T15:37:29+00:00

zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being optimized away by gcc.

Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
that can be used in such cases where a variable with sensitive data is
being cleared out in the end. Other use cases might also be in crypto
code. [ I have put this into lib/string.c though, as it's always built-in
and doesn't need any dependencies then. ]

Fixes kernel bugzilla: 82041

Reported-by: zatimend@hotmail.co.uk
Signed-off-by: Daniel Borkmann 
Acked-by: Hannes Frederic Sowa 
Cc: Alexey Dobriyan 
Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org

drivers/char/random: Replace __get_cpu_var uses

2014-08-26T17:45:45+00:00

A single case of using __get_cpu_var for address calculation.

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Christoph Lameter 
Signed-off-by: Tejun Heo