linux-stable.git/drivers/char, branch linux-3.15.y

hwrng: virtio - ensure reads happen after successful probe

2014-07-31T19:44:09+00:00

commit e052dbf554610e2104c5a7518c4d8374bed701bb upstream.

The hwrng core asks for random data in the hwrng_register() call itself
from commit d9e7972619.  This doesn't play well with virtio -- the
DRIVER_OK bit is only set by virtio core on a successful probe, and
we're not yet out of our probe routine when this call is made.  This
causes the host to not acknowledge any requests we put in the virtqueue,
and the insmod or kernel boot process just waits for data to arrive from
the host, which never happens.

CC: Kees Cook 
CC: Jason Cooper 
CC: Herbert Xu 
Reviewed-by: Jason Cooper 
Signed-off-by: Amit Shah 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

random: check for increase of entropy_count because of signed conversion

2014-07-28T15:08:27+00:00

commit 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc upstream.

The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
actually increase entropy_count if during assignment of the unsigned
expression on the RHS (mind the -=) we reduce the value modulo
2^width(int) and assign it to entropy_count. Trinity found this.

[ Commit modified by tytso to add an additional safety check for a
  negative entropy_count -- which should never happen, and to also add
  an additional paranoia check to prevent overly large count values to
  be passed into urandom_read().  ]

Reported-by: Dave Jones 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

hwrng: fetch randomness only after device init

2014-07-28T15:08:27+00:00

commit d3cc7996473a7bdd33256029988ea690754e4e2a upstream.

Commit d9e7972619334 "hwrng: add randomness to system from rng sources"
added a call to rng_get_data() from the hwrng_register() function.
However, some rng devices need initialization before data can be read
from them.

This commit makes the call to rng_get_data() depend on no init fn
pointer being registered by the device.  If an init function is
registered, this call is made after device init.

CC: Kees Cook 
CC: Jason Cooper 
CC: Herbert Xu 
Signed-off-by: Amit Shah 
Reviewed-by: Jason Cooper 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

i8k: Fix non-SMP operation

2014-07-17T23:23:09+00:00

commit 6d827fbcc370ca259a2905309f64161ab7b10596 upstream.

Commit f36fdb9f0266 (i8k: Force SMM to run on CPU 0) adds support
for multi-core CPUs to the driver. Unfortunately, that causes it
to fail loading if compiled without SMP support, at least on
32 bit kernels. Kernel log shows "i8k: unable to get SMM Dell
signature", and function i8k_smm is found to return -EINVAL.

Testing revealed that the culprit is the missing return value check
of set_cpus_allowed_ptr.

Fixes: f36fdb9f0266 (i8k: Force SMM to run on CPU 0)
Reported-by: Jim Bos 
Tested-by: Jim Bos 
Signed-off-by: Guenter Roeck 
Cc: Andreas Mohr 
Signed-off-by: Greg Kroah-Hartman

random: fix nasty entropy accounting bug

2014-07-01T03:14:04+00:00

commit e33ba5fa7afce1a9f159704121d4e4d110df8185 upstream.

Commit 0fb7a01af5b0 "random: simplify accounting code", introduced in
v3.15, has a very nasty accounting problem when the entropy pool has
has fewer bytes of entropy than the number of requested reserved
bytes.  In that case, "have_bytes - reserved" goes negative, and since
size_t is unsigned, the expression:

       ibytes = min_t(size_t, ibytes, have_bytes - reserved);

... does not do the right thing.  This is rather bad, because it
defeats the catastrophic reseeding feature in the
xfer_secondary_pool() path.

It also can cause the "BUG: spinlock trylock failure on UP" for some
kernel configurations when prandom_reseed() calls get_random_bytes()
in the early init, since when the entropy count gets corrupted,
credit_entropy_bits() erroneously believes that the nonblocking pool
has been fully initialized (when in fact it is not), and so it calls
prandom_reseed(true) recursively leading to the spinlock BUG.

The logic is *not* the same it was originally, but in the cases where
it matters, the behavior is the same, and the resulting code is
hopefully easier to read and understand.

Fixes: 0fb7a01af5b0 "random: simplify accounting code"
Signed-off-by: Theodore Ts'o 
Cc: Greg Price 
Signed-off-by: Greg Kroah-Hartman

applicom: dereferencing NULL on error path

2014-07-01T03:13:53+00:00

commit 8bab797c6e5724a43b7666ad70860712365cdb71 upstream.

This is a static checker fix.  The "dev" variable is always NULL after
the while statement so we would be dereferencing a NULL pointer here.

Fixes: 819a3eba4233 ('[PATCH] applicom: fix error handling')
Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman

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

2014-05-21T09:56:35+00:00

Pull /dev/random fix from Ted Ts'o:
 "This fixes a BUG_ON-causing regression that was introduced during the
  last merge window"

* tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
  random: fix BUG_ON caused by accounting simplification

random: fix BUG_ON caused by accounting simplification

2014-05-17T02:18:22+00:00

Commit ee1de406ba6eb1 ("random: simplify accounting logic") simplified
things too much, in that it allows the following to trigger an
overflow that results in a BUG_ON crash:

dd if=/dev/urandom of=/dev/zero bs=67108707 count=1

Thanks to Peter Zihlstra for discovering the crash, and Hannes
Frederic for analyizing the root cause.

Signed-off-by: "Theodore Ts'o" 
Reported-by: Peter Zijlstra 
Reported-by: Hannes Frederic Sowa 
Cc: Greg Price

ACPI / TPM: Fix resume regression on Chromebooks

2014-05-11T23:13:28+00:00

Chromebooks (at least Acer C720 and Pixel) implement an ACPI object
for TPM, but don't implement the _DSM method to support PPI.  As
a result, the TPM driver fails to load on those machines after
commit 1569a4c4ceba (ACPI / TPM: detect PPI features by checking
availability of _DSM functions) which causes them to fail to
resume from system suspend, becuase they require the TPM hardware
to be put into the right state during resume and the TPM driver
is necessary for that.

Fix the problem by making tpm_add_ppi() return 0 when tpm_ppi_handle
is still NULL after walking the ACPI namespace in search for the PPI
_DSM, which allows the TPM driver to load and operate the hardware
(during system resume in particular), but avoid creating the PPI
sysfs group in that case.

This change is based on a prototype patch from Jiang Liu.

Fixes: 1569a4c4ceba (ACPI / TPM: detect PPI features by checking availability of _DSM functions)
References: https://bugzilla.kernel.org/show_bug.cgi?id=74021
Reported-by: James Duley 
Reported-by: Phillip Dixon 
Tested-by: Brandon Casey 
Cc: 3.14+  # 3.14+
Signed-off-by: Rafael J. Wysocki

agp: info leak in agpioc_info_wrap()

2014-05-06T20:05:00+00:00

On 64 bit systems the agp_info struct has a 4 byte hole between
->agp_mode and ->aper_base.  We need to clear it to avoid disclosing
stack information to userspace.

Signed-off-by: Dan Carpenter 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds