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

random: use chacha20 for get_random_int/long

2017-04-12T10:41:15+00:00

commit f5b98461cb8167ba362ad9f74c41d126b7becea7 upstream.

Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.

We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.

Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.

Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.

Signed-off-by: Jason A. Donenfeld 
Suggested-by: Theodore Ts'o 
Cc: Theodore Ts'o 
Cc: Hannes Frederic Sowa 
Cc: Andy Lutomirski 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ppdev: fix registering same device name

2017-04-12T10:41:10+00:00

commit 9a69645dde1188723d80745c1bc6ee9af2cbe2a7 upstream.

Usually every parallel port will have a single pardev registered with
it. But ppdev driver is an exception. This userspace parallel port
driver allows to create multiple parrallel port devices for a single
parallel port. And as a result we were having a big warning like:
"sysfs: cannot create duplicate filename '/devices/parport0/ppdev0.0'".
And with that many parallel port printers stopped working.

We have been using the minor number as the id field while registering
a parralel port device with a parralel port. But when there are
multiple parrallel port device for one single parallel port, they all
tried to register with the same name like 'pardev0.0' and everything
started failing.
Use an incremented index as the id instead of the minor number.

Fixes: 8b7d3a9d903e ("ppdev: use new parport device model")
Cc: stable  # v4.9+
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1414656
Bugzilla: https://bugs.archlinux.org/task/52322
Tested-by: James Feeney 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

ppdev: check before attaching port

2017-04-12T10:41:10+00:00

commit dd5c472a60e43549d789a17a8444513eec64bd7e upstream.

After parport starts using the device model, all pardevice drivers
should decide in their match_port callback function if they want to
attach with that particulatr port. ppdev has been converted to use the
new parport device-model code but pp_attach() tried to attach with all
the ports.
Create a new array of pointer and use that to remember the ports we
have attached. And use that information to skip attaching ports which
we have already attached.

Tested-by: Joe Lawrence 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

hwrng: geode - Revert managed API changes

2017-03-30T07:41:26+00:00

commit 8c75704ebcac2ffa31ee7bcc359baf701b52bf00 upstream.

After commit e9afc746299d ("hwrng: geode - Use linux/io.h instead of
asm/io.h") the geode-rng driver uses devres with pci_dev->dev to keep
track of resources, but does not actually register a PCI driver.  This
results in the following issues:

1.  The driver leaks memory because the driver does not attach to a
device.  The driver only uses the PCI device as a reference.   devm_*()
functions will release resources on driver detach, which the geode-rng
driver will never do.  As a result,

2.  The driver cannot be reloaded because there is always a use of the
ioport and region after the first load of the driver.

Revert the changes made by  e9afc746299d ("hwrng: geode - Use linux/io.h
instead of asm/io.h").

Signed-off-by: Prarit Bhargava 
Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API")
Cc: Matt Mackall 
Cc: Corentin LABBE 
Cc: PrasannaKumar Muralidharan 
Cc: Wei Yongjun 
Cc: linux-crypto@vger.kernel.org
Cc: linux-geode@lists.infradead.org
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

hwrng: amd - Revert managed API changes

2017-03-30T07:41:26+00:00

commit 69db7009318758769d625b023402161c750f7876 upstream.

After commit 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"), the
amd-rng driver uses devres with pci_dev->dev to keep track of resources,
but does not actually register a PCI driver.  This results in the
following issues:

1. The message

WARNING: CPU: 2 PID: 621 at drivers/base/dd.c:349 driver_probe_device+0x38c

is output when the i2c_amd756 driver loads and attempts to register a PCI
driver.  The PCI & device subsystems assume that no resources have been
registered for the device, and the WARN_ON() triggers since amd-rng has
already do so.

2.  The driver leaks memory because the driver does not attach to a
device.  The driver only uses the PCI device as a reference.   devm_*()
functions will release resources on driver detach, which the amd-rng
driver will never do.  As a result,

3.  The driver cannot be reloaded because there is always a use of the
ioport and region after the first load of the driver.

Revert the changes made by 31b2a73c9c5f ("hwrng: amd - Migrate to managed
API").

Signed-off-by: Prarit Bhargava 
Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API").
Cc: Matt Mackall 
Cc: Corentin LABBE 
Cc: PrasannaKumar Muralidharan 
Cc: Wei Yongjun 
Cc: linux-crypto@vger.kernel.org
Cc: linux-geode@lists.infradead.org
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

tpm_tis: fix the error handling of init_tis()

2017-03-12T05:41:43+00:00

commit 5939eaf4f9d432586dd2cdeea778506471e8088e upstream.

Add the missing platform_driver_unregister() and remove the duplicate
platform_device_unregister(force_pdev) in the error handling case.

Fixes: 00194826e6be ("tpm_tis: Clean up the force=1 module parameter")
Signed-off-by: Wei Yongjun 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

drivers: char: mem: Fix thinkos in kmem address checks

2017-01-19T19:18:03+00:00

commit 488debb9971bc7d0edd6d8080ba78ca02a04f6c4 upstream.

When borrowing the pfn_valid() check from mmap_kmem(), somebody managed
to get physical and virtual addresses spectacularly muddled up, such
that we've ended up with checks for one being the other. Whilst this
does indeed prevent out-of-bounds accesses crashing, on most systems
it also prevents the more desirable use-case of working at all ever.

Check the *virtual* offset correctly for what it is. Furthermore, do
so in the right place - a read or write may span multiple pages, so a
single up-front check is insufficient. High memory accesses already
have a similar validity check just before the copy_to_user() call, so
just make the low memory path fully consistent with that.

Reported-by: Jason A. Donenfeld 
Fixes: 148a1bc84398 ("drivers: char: mem: Check {read,write}_kmem() addresses")
Signed-off-by: Robin Murphy 
Signed-off-by: Greg Kroah-Hartman

tpm_tis: Check return values from get_burstcount.

2017-01-12T10:39:38+00:00

commit 26a137e31ffe6fbfdb008554a8d9b3d55bd5c86e upstream.

If the TPM we're connecting to uses a static burst count, it will report
a burst count of zero throughout the response read. However, get_burstcount
assumes that a response of zero indicates that the TPM is not ready to
receive more data. In this case, it returns a negative error code, which
is passed on to tpm_tis_{write,read}_bytes as a u16, causing
them to read/write far too many bytes.

This patch checks for negative return codes and bails out from recv_data
and tpm_tis_send_data.

Fixes: 1107d065fdf1 (tpm_tis: Introduce intermediate layer for TPM access)
Signed-off-by: Josh Zimmerman 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm xen: Remove bogus tpm_chip_unregister

2017-01-06T09:40:17+00:00

commit 1f0f30e404b3d8f4597a2d9b77fba55452f8fd0e upstream.

tpm_chip_unregister can only be called after tpm_chip_register.
devm manages the allocation so no unwind is needed here.

Fixes: afb5abc262e96 ("tpm: two-phase chip management functions")
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'

2016-11-18T00:31:09+00:00

The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
other is H8S/2168 compliant.

The current ipmi/bt-bmc driver implements the IPMI version and we
should reflect its nature in the compatible node name using
'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
latter should be used for a H8S interface driver if it is implemented
one day.

Signed-off-by: Cédric Le Goater 
Signed-off-by: Olof Johansson