linux-stable.git/drivers/char, branch v4.7.7

tpm_crb: fix mapping of the buffers

2016-10-07T13:21:27+00:00

commit 422eac3f7deae34dbaffd08e03e27f37a5394a56 upstream.

On my Lenovo x250 the following situation occurs:

[18697.813871] tpm_crb MSFT0101:00: can't request region for resource
[mem 0xacdff080-0xacdfffff]

The mapping of the control area overlaps the mapping of the command
buffer. The control area is mapped over page, which is not right. It
should mapped over sizeof(struct crb_control_area).

Fixing this issue unmasks another issue. Command and response buffers
can overlap and they do interleave on this machine. According to the PTP
specification the overlapping means that they are mapped to the same
buffer.

The commit has been also on a Haswell NUC where things worked before
applying this fix so that the both code paths for response buffer
initialization are tested.

Cc: stable@vger.kernel.org
Fixes: 1bd047be37d9 ("tpm_crb: Use devm_ioremap_resource")
Signed-off-by: Jarkko Sakkinen 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

tpm_crb: drop struct resource res from struct crb_priv

2016-10-07T13:21:27+00:00

commit 14ddfbf488a0223b19abf7e4634e6e676a91a12d upstream.

The iomem resource is needed only temporarily so it is better to pass
it on instead of storing it permanently. Named the variable as io_res
so that the code better documents itself.

Signed-off-by: Jarkko Sakkinen 
Reviewed-by: Stefan Berger 
Signed-off-by: Greg Kroah-Hartman

hwrng: omap - Fix assumption that runtime_get_sync will always succeed

2016-10-07T13:21:22+00:00

commit 61dc0a446e5d08f2de8a24b45f69a1e302bb1b1b upstream.

pm_runtime_get_sync does return a error value that must be checked for
error conditions, else, due to various reasons, the device maynot be
enabled and the system will crash due to lack of clock to the hardware
module.

Before:
12.562784] [00000000] *pgd=fe193835
12.562792] Internal error: : 1406 [#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
[...]

After the proper checks:
[   94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME:
missing hwmod/omap_dev info
[   94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19
[   94.382351] omap_rng 48090000.rng: initialization failed.

Fixes: 665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM")
Cc: Paul Walmsley 
Signed-off-by: Nishanth Menon 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

tpm: fix byte-order for the value read by tpm2_get_tpm_pt

2016-10-07T13:21:21+00:00

commit 1b0612b04090e416828c0dd5ed197b0913d834a0 upstream.

The result must be converted from BE byte order, which is used by the
TPM2 protocol. This has not popped out because tpm2_get_tpm_pt() has
been only used for probing.

Fixes: 7a1d7e6dd76a ("tpm: TPM 2.0 baseline support")
Change-Id: I7d71cd379b1a3b7659d20a1b6008216762596590
Signed-off-by: Andrey Pronin 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm_crb: fix address space of the return pointer in crb_map_res()

2016-08-20T16:10:58+00:00

commit f786b752098216fedb73ba2905c8cce12358534a upstream.

When running make C=2 M=drivers/char/tpm/

  CHECK   drivers/char/tpm//tpm_crb.c
drivers/char/tpm//tpm_crb.c:248:31: warning: incorrect type in return expression (different address spaces)
drivers/char/tpm//tpm_crb.c:248:31:    expected void [noderef] *
drivers/char/tpm//tpm_crb.c:248:31:    got void *

Fixes: 1bd047be37d9 ("tpm_crb: Use devm_ioremap_resource")
Signed-off-by: Jarkko Sakkinen 
Tested-by: Stefan Berger 
Signed-off-by: Greg Kroah-Hartman

random: print a warning for the first ten uninitialized random users

2016-08-20T16:10:55+00:00

commit 9b4d008787f864f17d008c9c15bbe8a0f7e2fc24 upstream.

Since systemd is consistently using /dev/urandom before it is
initialized, we can't see the other potentially dangerous users of
/dev/urandom immediately after boot.  So print the first ten such
complaints instead.

Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

random: initialize the non-blocking pool via add_hwgenerator_randomness()

2016-08-20T16:10:55+00:00

commit 3371f3da08cff4b75c1f2dce742d460539d6566d upstream.

If we have a hardware RNG and are using the in-kernel rngd, we should
use this to initialize the non-blocking pool so that getrandom(2)
doesn't block unnecessarily.

Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

random: properly align get_random_int_hash

2016-08-20T16:10:55+00:00

commit b1132deac01c2332d234fa821a70022796b79182 upstream.

get_random_long() reads from the get_random_int_hash array using an
unsigned long pointer.  For this code to be guaranteed correct on all
architectures, the array must be aligned to an unsigned long boundary.

Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

random: add interrupt callback to VMBus IRQ handler

2016-08-20T16:10:55+00:00

commit 4b44f2d18a330565227a7348844493c59366171e upstream.

The Hyper-V Linux Integration Services use the VMBus implementation for
communication with the Hypervisor. VMBus registers its own interrupt
handler that completely bypasses the common Linux interrupt handling.
This implies that the interrupt entropy collector is not triggered.

This patch adds the interrupt entropy collection callback into the VMBus
interrupt handler function.

Signed-off-by: Stephan Mueller 
Signed-off-by: Stephan Mueller 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

random: strengthen input validation for RNDADDTOENTCNT

2016-08-16T07:34:58+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